2 3 Оглавление _Toc265065079ВВЕДЕНИЕ ........................................................................................ 6 1 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ ................................................................ 7 1.1 1.2 1.3 1.4 ПРЕДМЕТНАЯ ОБЛАСТЬ ...................................................................................................7 ПОСТАНОВКА ЗАДАЧИ ....................................................................................................7 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ .....................................................................................8 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНЫМ ПОДСИСТЕМАМ ....................................9 2 ПРОЕКТИРОВАНИЕ ПОДСИСТЕМ ....................................................... 11 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 АНАЛИЗ МОДИФИЦИРУЕМОЙ СИСТЕМЫ .......................................................................11 ВЫБОР ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ СИСТЕМЫ ...................................................12 ВЫБОР МОДЕЛИ ПРОЕКТИРОВАНИЯ ..............................................................................16 РЕШЕНИЯ ПО КОМПЛЕКСУ ТЕХНИЧЕСКИХ СРЕДСТВ .....................................................17 ВЫБОР ПРОГРАММНЫХ СРЕДСТВ ..................................................................................19 C# 3.5, ASP.NET ..........................................................................................................23 MSSQL 2008EXPRESS ..................................................................................................23 ИТОГОВЫЕ ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ВЫБОРУ ПО .........................................24 3 АРХИТЕКТУРА РАЗРАБАТЫВАЕМЫХ ПОДСИСТЕМ.................... 26 ОПИСАНИЕ И МОДЕЛЬ ПОДСИСТЕМЫ ОТЧЕТНОСТИ, ОБЩЕЕ ОПИСАНИЕ ПРИНЦИПОВ ФУНКЦИОНИРОВАНИЯ ................................................................................................................26 3.2 ОПИСАНИЕ МОДЕЛИ ПОДСИСТЕМЫ МЕТОДИЧЕСКИХ ПОСОБИЙ ...................................29 3.1 4 ОПИСАНИЕ ИНТЕРФЕЙСА ..................................................................... 33 ИНТЕРФЕЙС ПРЕПОДАВАТЕЛЯ.......................................................................................33 4.1.1 Подсистема отчетности для преподавателя ................................................... 33 4.1.2 Подсистема просмотра и редактирования методических материалов по предметам для преподавателя...................................................................................... 36 4.1.3 Подсистема общей отчетности для лектора и преподавателя-практика ........ 38 4.2 ИНТЕРФЕЙС СТУДЕНТА .................................................................................................38 4.1 ЗАКЛЮЧЕНИЕ ................................................................................................... 40 ЛИТЕРАТУРА ..................................................................................................... 42 ПРИЛОЖЕНИЕ 1................................................................................................ 43 ПРИЛОЖЕНИЕ 2................................................................................................ 45 4 ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ БД — база данных ВУЗ — высшее учебное заведение Гб — гигабайт ЖЦ — жизненный цикл ИС — информационная система Мб — мегабайт ОС — операционная система ОЗУ — оперативное запоминающее устройство (оперативная память) ПО — программное обеспечение ПЭВМ — персональная ЭВМ СУБД — система управления базами данных СПБГУАП – Санкт-Петербургский государственный университет аэрокосмического приборостроения ТЗ — техническое задание ЭВМ — электронная вычислительная машина 5 ВВЕДЕНИЕ Информатизация учебного заведения представляет собой комплекс мероприятий, нацеленных на применение средств информационных технологий для повышения эффективности процессов обработки информации во всех, без исключения, видах деятельности современного образовательного учреждения. Основополагающим в этом комплексе мероприятий является процесс ведения документации в электронном виде. Для перевода документооборота в электронный вид и для решения проблемы информатизации на базе кафедры 43 СПБГУАП была разработана информационная система рейтинговых ведомостей, которая позволила учитывать успеваемость студентов на всех типах занятий. Данная дипломная работа представляет собой разработку подсистемы отчетности рейтинговых ведомостей, которая является основной в таких системах. Как следствие, разработку подсистемы общей отчетности, для учета успеваемости студентов на лекционных занятиях и выставления итоговой оценки. Также в этой дипломной работе представлена подсистема, автоматизирующая предоставление актуального обучающего материала для студентов. 6 1 1.1 ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ Предметная область Рассматриваемая предметная область – рейтинговая система оценки успеваемости студентов на кафедре СПБГУАП. 1.2 Постановка задачи В дипломной работе поставлена задача внести изменения в разработанный ранее проект и добавить новый функционал согласно техническому заданию. А именно: 1. Подсистему отчетности позволяющую: Просматривать и распечатывать ведомость об успеваемости студентов Обеспечить возможность экспорта данных в традиционные форматы Excel и PDF 2. Подсистему просмотра и редактирования методических материалов по предметам, позволяющую: Хранить и редактировать данные о дисциплине (список рекомендуемой литературы, методические пособия и т.д.) Просматривать данные о предметах на web-странице Загружать доступные материалы на локальный компьютер 3. Подсистему общей отчетности для лектора и преподавателя практики, позволяющую: Учитывать успеваемость студентов на всех типах занятий Вывести итоговую оценку Для выполнения поставленных задач необходимо: Провести анализ созданного проекта 7 Определить программные средства для реализации создаваемых систем Разработать интерфейс взаимодействия пользователя с системой 1.3 Анализ предметной области На основе описания предметной области и поставленной задачи проводится анализ предметной области с целью выявления: Пользователей системы Недостатков системы и способов их устранения Ограничений для разных групп пользователей Из описания предметной области можно выделить несколько ролей для внешних пользователей системы: Студент – лицо, которое может просматривать информацию о своей текущей успеваемости, данных о предмете. Преподаватель – основное действующее лицо – занимается редактированием успеваемости студентов, их посещаемости занятий, редактированием данных о предмете. Проведя анализ существующего проекта можно сделать вывод, что некоторые функциональные решения являются непрактичными в использовании. Для данного проекта подсистема отчетности существовала в виде htmlстраницы, что являлось существенным недостатком, так как подобное представление не поддается стандартизированному форматированию, может отличаться в разных браузерах и требует сложной последовательности действий для дальнейшей аналитической обработки. В 8 связи с этим, возникла необходимость нового подхода к генерации отчетности, позволяющего заполнять отчеты имеющимися данными по заданному формату (PDF) и возможностью экспорта в Excel для дальнейшей обработки в случае необходимости. Также в проекте существовала страница методических пособий по лабораторным работам, но она имела ограниченную функциональность, так как отсутствовала возможность просмотра пособий вне кафедры. Необходимость в доступе к пособиям с любого компьютера, подключенного к интернету для студентов вечернего и заочного отделений, и просмотр этих данных, повлекли за собой решение усовершенствовать систему методических пособий и расширить ее применение. 1.4 Определение требований к программным подсистемам Основные цели разработки структуры системы отчетности заключаются в том, чтобы обеспечить пользователей точными данными, которые необходимы им для исполнения своих служебных обязанностей, а также для быстрого доступа к этим данным. Подсистема отчетности должна быть: универсальной, простой в использовании, наиболее подходящей для разработки в существующем проекте. Следует отметить, что для разработки такой подсистемы необходимо провести анализ доступных методов разработки генераторов отчетов, выяснить их недостатки и достоинства, определить, какой метод наиболее оптимален для нашей системы. 9 Разработка системы методических пособий по лабораторным работам должна заключаться в том, чтобы обеспечить возможность: просмотра данных; добавления методических пособий и дополнительных материалов; удаления невостребованных данных. Подсистема просмотра методических пособий должна подходить для большинства типов файлов, используемых в документообороте (графических, текстовых, pdf, djvu), что делает ее универсальной. Также данная подсистема должна иметь простой интерфейс. Проектирование необходимых нам следующие этапы: Определение предметной области Проектирование систем Реализация систем 10 систем включает в себя 2 2.1 ПРОЕКТИРОВАНИЕ ПОДСИСТЕМ Анализ модифицируемой системы Информационная система LabTracker позволила значительно увеличить качество и удобство ведения практических лабораторных занятий в рамках рейтинговой системой ВУЗа. В настоящее время в системе реализован web-интерфейс пользователей, разделенный на 3группы: преподаватели, студенты, администраторы. Преподаватели имеют защищенный доступ к данным, что очень важно, если учитывать, что другая группа пользователей имеет прямую заинтересованность в изменении этих данных. Также они могут выбирать группу, предмет и режим преподавания: основной и замещение. Преподаватели заносят баллы в электронную ведомость, сохраняют изменения, проставляют посещаемость. Автоматически суммируются баллы, и выставляется дата поставленной оценки. Общие результаты по группе можно просмотреть на web-странице. Студенты имеют открытый доступ к данным. При аутентификации пользователя студент выбирает свою группу, имя пользователя (из списка группы) и вводит единый для них пароль – user. На странице студенту выводятся баллы за лабораторные работы по тем дисциплинам, которые у него преподаются. Единым представлением и для преподавателя, и для студента являются методические пособия. При нажатии на название лабораторной работы, открывается новая страница с методическими указаниями и 11 вариантами заданий. Эти данные невозможно просмотреть, находясь вне локальной сети кафедры, что существенно усложняет процесс обучения студентов заочного и вечернего обучения. 2.2 Выбор жизненного цикла разработки системы Одним из информационных базовых систем понятий является методологии понятие программного обеспечения (ЖЦ ПО). ЖЦ ПО – проектирования жизненного цикла ее это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадная модель (70-85 г.г.); спиральная модель (86-90 г.г.). В изначально существовавших однородных информационных системах каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит, только после того, как будет полностью завершена работа на текущем этапе (Рис.1). 12 Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Рис. 1. Каскадная модель ЖЦ Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных, прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания 13 ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (Рис.2), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. 14 Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.1 Рис. 2. Спиральная модель ЖЦ Так как в рамках реализации проекта разрабатывается комплекс программных решений и предполагается активное участие в разработке заказчика, то была выбрана спиральная модель жизненного цикла, как наиболее соответствующая поставленным условиям. 1 http://www.studfiles.ru/dir/cat32/subj1340/file14246/view142176.html 15 2.3 Выбор модели проектирования Методы, используемые при проектировании программных систем можно условно разделить на три большие группы: метод структурного проектирования сверху вниз; метод потоков данных; объектно-ориентированное проектирование. В 60-70-е годы было разработано много методов, помогающих справится с растущей сложностью программ. Наибольшее распространение получило структурное проектирование по методу сверху вниз. Метод был непосредственно основан на топологии традиционных языков высоко уровня типа FORTRAN или COBOL. В этих языках основной базовой единицей является подпрограмма, и программа в целом принимает форму дерева, в котором одни подпрограммы в процессе работы вызывают другие подпрограммы. Структурное программирование использует именно такой подход: алгоритмическая декомпозиция применяется для разбиения большой задачи на более мелкие. Необходимо отметить, что большинство существующих программ написано, по-видимому, в соответствии с этим методом. Тем не менее, структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный подход не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектно-ориентированных языках программирования.2 В методе потоков данных программная система рассматривается как преобразователь входных потоков в выходные. Метод потоков данных, как и структурный метод, с успехом применялся при решении ряда сложных 2 http://www.helloworld.ru/texts/comp/other/oop/ch01.htm 16 задач, в частности, в системах информационного обеспечения, где существуют прямые связи между входными и выходными потоками системы, и где не требуется уделять особого внимания быстродействию. Объектно-ориентированное проектирование (object-oriented design, OOD) – это подход, в основу которого положено представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию. Объектно-ориентированный подход отражает топологию языков высокого уровня, таких как Delphi, C++ и C#. Общая концепция ИС предполагает реализацию совокупности объектов и их взаимодействие, поэтому реализацию системы было решено создавать на базе объектно-ориентированного подхода с применением языка высокого уровня C# 3.5. 2.4 Решения по комплексу технических средств Среди всего множества критериев отбора технических средств нас интересуют: достаточный объем оперативного запоминающего устройства сервера; достаточный объем накопителя на жестком магнитном диске сервера; приемлемый тип видеоадаптера и дисплея для работы пользователя; достаточная производительность центрального процессора сервера; наличие возможности вывода информации на бумажный, магнитный носитель; 17 достаточная скорость передачи данных в локальной сети; приемлемая стоимость составляющих комплекса технических средств. Объем необходимого ОЗУ рассчитывается, исходя из размеров памяти, занимаемой необходимого объема загружаемой памяти, операционной выделяемого под системой, драйверы из для обслуживания ЭВМ, программы-оболочки, основного загружаемого модуля программного комплекса, динамических библиотек, подгружаемых по мере выполнения программы и резерва памяти для обработки информации. Исходя из вышеизложенного, приходим, что для нормальной работы системы необходимо не менее 1024 Мбайт ОЗУ. По современным понятиям, это уже не слишком высокое требование объясняется тем, что для нормальной работы, выбранной в качестве рекомендуемой ОС системы WindowsXP необходимо не менее 512 Мбайт оперативной памяти. Подбор объема накопителя на жестком магнитном диске, далее HDD основывается на размере обрабатываемых данных, в момент предполагаемой пиковой загруженности, занимаемом ОС объемом жесткого диска, а также на размере архивов создаваемых системой за прошлые годы. Так же следует учесть необходимое быстродействие HDD, в зависимости от потребности в скорости реакции системы. Предполагаемый срок службы техники – 5 лет. Так как 5 лет – средний срок полного морального устаревания парка машин и его замены. Скорость передачи данных в ЛВС зависит от выбранного сетевого программного и технического обеспечения. Парк применяемых машин на предприятии заказчика оснащен Ethernet-адаптерами и прочими сетевыми устройствами со скоростью передачи данных 100Mбит/сек. Учитывая достаточность этой скорости для работы системы, принято решение использовать имеющиеся средства. 18 Итак, подведем итоги выше приведенных рассуждений и выдвинем комплексные требования к составу технических средств, необходимых для функционирования системы. Сервер (минимальные требования): процессор не хуже PentiumIV 1ГГц объем ОЗУ не менее 1024 Мб объем жесткого диска не менее 10 Гб(свободно не менее 1ГБ) Сетевая карта Клиент: процессор не хуже PentiumII400 МГц объем ОЗУ не менее 512Мб; графический адаптер не хуже SVGA16Мб; монитор не хуже SVGA 0.26, 15 дюймов сетевая карта 2.5 Выбор программных средств Выбор программных средств является одной из важнейших задач при разработке программного продукта. В рассматриваемой разработке необходимо определить генератор отчетов. На сегодняшний день на современном рынке технологий представлено множество продуктов и разработок, связанных с генерацией отчетов. При выборе средства программирования и генерации отчетов необходимо определить основные требования: Удобство разработки / модификации – т.е. является ли генератор встроенным приложением или отдельным программным продуктом, требующим внедрения 19 Экспорт в различные форматы – позволяет расширить возможности отчетности Печать отчетов Стоимость – крайне важный параметр при ограниченном бюджете ВУЗа. В таблице 1 дана сравнительная характеристика всех выбранных для анализа генераторов отчетов. Таблица 1 Внешний/встроенный внешний внешний Microsoft Reporting Services встроенный Экспорт есть есть есть нет нет Печать есть есть есть нет есть Стоимость высокая высокая бесплатно бесплатно высокая FastReport.Net Crystal Reporting Open XML Excel+ database встроенный встроенный При просмотре Таблицы 1 можно сделать вывод, что оптимальным программным средством для разрабатываемой являетсяMicrosoftReportingServices. Данный системы отчетности компонент является встроенным в VisualStudio 2008, он поставляется в комплекте с SQLServer, который предоставлен в бесплатной Express-версии, соответственно тоже является бесплатным, он предоставляет возможность экспортирования данных в Excel и PDF, печать сформированных отчетов. ReportingServices включает графическую оболочку для создания отчетов - ReportDesigner, которая использует интегрированную среду разработки VisualStudio .NET и позволяет обойтись без написания кода. С помощью ReportDesigner можно настраивать источники данных и конструирования запросов, добавлять в отчет так называемые регионы 20 данных и поля, определять разметку отчета и включать в него интерактивные средства. ReportWizard облегчает создание отчета. Отчет с загруженными в него данными можно просмотреть предварительно, а как только он будет готов, ReportDesigner опубликует его на сервере отчетов посредством ReportingServices SOAP API. ReportingServices для формирования отчета использует отраслевой XML-стандарт - ReportDefinitionLanguage (RDL), который помимо удобства передачи данных обеспечивает совместимость с различными инструментами третьих фирм. Исходные данные могут извлекаться из широкого спектра источников, в том числе реляционных, иерархических и многомерных БД. Напрямую поддерживаются MS SQL Server 2005 и SQL Server2008, Oracle, OLE DB-совместимые источники данных, включая AnalysisServices, а также ODBC. Возможно подключение и других источников данных через открытый набор API на базе .NET.3 В процессе выбора модели проектирования был выбран объектноориентированный подход и язык программирования C# 3.5 и следующие средства: СУБД – MS SQLServer 2008Express IDE – MS Visual Studio 2008 Express Определяющими критериями для выбора программных средств разработки, рассматриваемого программного продукта являются стоимость разработки (все средства разработки являются бесплатно- распространяемыми) и возможности, предоставляемые этими средствами, которые полностью удовлетворяют поставленным задачам. Кроме выбора программных средств для проектирования наших систем необходимо выбрать наиболее подходящие специальные технологии 3 http://www.interface.ru/home.asp?artId=968 21 и методы, используемые разрабатываемой системой, это обусловлено тем, что в настоящее время существует множество технологий, реализуемых выбранными программными средствами разработки ПО, в связи, с чем для разрабатываемой системы были выбраны следующие специальные технологии: AJAX ASP.NET LINQ Выбор именно этих технологий обусловлен тем, что они полностью поддерживаются выбранными программными средствами и полностью удовлетворяют всем поставленным задачам и реализуют весь необходимый функционал. 22 2.6 C# 3.5, ASP.NET Выбор в качестве пользовательского интерфейса решения, основанном на отображении информации в web-браузере, предполагает собой выбор технологии создания web-приложений. В качестве такой технологии была выбрана технология ASP.NET, как наиболее удовлетворяющая всем потребностям разработки: В качестве языка программирования для разработки системы может использоваться язык C# 3.5, который был выбран при выборе модели проектирования Полная интеграция с СУБД MS SQL Server 2008 Полная поддержка спецификации IE 7.0, как наиболее используемого web-браузера. Язык C# 3.5 был выбран как наиболее подходящий для разработки в связи с выбором объектно-ориентированного подхода к проектированию системы и позволяющий, использовать все возможности .NET Framework, ASP.NET и LINQ , фактически являясь частью этих технологий. 2.7 MSSQL 2008Express Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую являющуюся название реализацией множественными (сокращённо Transact-SQL SQL-92 расширениями. (стандарт T-SQL для ISO позволяет T-SQL), SQL) с использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня 23 приложения под названием TabularDataStream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS, с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase. SQL Server поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL — это совокупность одинаково конфигурированных серверов; такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер. Основаниями для выбора стали следующие свойства SQL Server 2008: Бесплатность SQLServer 2008Express Полная поддержка .NETFramework Полная интеграция с используемой средой разработки MS VisualStudio 2008 2.8 Итоговые требования, предъявляемые к выбору ПО Подводя итог анализа и выбора различных технических и программных средств, к ПО, установленному на серверной и клиентской машинах, предъявляются следующие требования: Для сервера: Windows Server 2003 и выше .net 3,5 и выше SQL Server 2005 и выше 24 MicrosoftReportingServices Для клиента: Windows XP и выше Браузер Internet Explorer Adobe Acrobat Reader Microsoft Office 25 3 3.1 АРХИТЕКТУРА РАЗРАБАТЫВАЕМЫХ ПОДСИСТЕМ Описание и модель подсистемы отчетности, общее описание принципов функционирования Существующая система разработана с использованием архитектуры клиент-сервер (рис. 3), когда между клиентом и ядром системы присутствуют посредники в виде web-браузера и web-сервера. Сторонние утилиты Клиент Веб-браузер БД Ядро системы Сеть Веб-сервер Рис.3. Архитектура системы Разрабатываемая подсистема отчетности должна удовлетворять данным требованиям. Создаваемая подсистема взаимодействует с БД при помощи запросов, написанных на языке C# с использованием LINQ. Основой взаимодействия между системой и БД являются хранимые процедуры, написанные на языке SQL. Для простоты использования и повышения защищенности приложения основные интерфейсы и сервисы взаимодействия между системой и БД вынесены в отдельную сборку LabTracker.Framework.dll. 26 Использование MicrosoftReportingServices предполагает работу с простыми типами данных, но информация необходимая для отчетов находится в классах. Поэтому нужно было перевести данные в простые типы. Для этого были написаны дополнительные функции MapDiscipline и MapScore, которые позволили использовать выбранные данные для отчетов. Количество лабораторных работ устанавливается автоматически при проверке ID дисциплины. Список студентов получается тоже автоматически при вводе ID группы и ID дисциплины и записывается в соответствующую графу. Также в отчете использованы такие поля как Bonus, SummaryScore, LabName и MaxBalls. Для того чтобы отчет был универсальным необходимо было сделать передаваемыми параметрами название дисциплины, группу, фамилию преподавателя, количество лабораторных работ и их названия. Эти параметры были включены в класс ReportParameter, который является встроенным в MicrosoftReportingServices и позволяет их использовать вне описанной внутренней структуры. Процесс создания отчета происходит в дизайнере MicrosoftReportingServices (Рис.4) – данный продукт поддерживает следующие основные типы отчетов: табличный - фиксированное количество столбцов; матричный - количество столбцов зависит от результата запроса; графический - данные представлены графически; свободная форма - данные на странице организованы в произвольном виде. 27 Рис.4. Дизайнер MicrosoftReportingServices В нашем отчете используется табличный отчет, но на некоторые столбцы наложены условия, такие как количество лабораторных работ. То есть если столбцов, выделенных под лабораторные работы больше, чем их количество, то они скрываются из видимости в отчете. В создаваемом отчете есть поле даты создания этого отчета, что является удобным для преподавателя – подводить статистику сданных работ на какое-то определенное число. В отчете скрываются баллы за лабораторные работы равные нулю, чтобы преподаватель мог вручную их доставлять уже в распечатанном виде. Готовый отчет (Рис.5), например группы 4736 по ООП, можно увидеть в Internet Explorer, при нажатии на кнопку «Экспорт», и распечатать. 28 Рис.5. Пример готового отчета Аналогичным способом составляется отчет о посещаемости студентов на лекционных занятиях. В отчете по лекциям содержится таблица с посещаемостью на определенный день, контрольная работа 1 и 2, итоговые баллы по практическим занятиям, суммарные баллы и рекомендованная оценка (Рис.6.). Рис.6.Отчет посещаемости студентов 3.2 Описание модели подсистемы методических пособий Подсистема методических пособий направлена на улучшение информированности студентов о лабораторных работах, экзаменах, методических пособиях и вспомогательных материалах. До начала 29 модификации системы невозможно было просматривать методические пособия вне локальной сети кафедры, не было возможностей добавления и удаления файлов, не возможно было просмотреть содержимое файлов (Рис.7). Рис.7. Информация о лабораторной работе Для того чтобы данная подсистема удовлетворяла требованиям необходимо было изменить структуру и содержание страницы. Страницу разделили на две части: слева – список файлов и функциональные кнопки, справа – просмотр содержимого этих файлов. Процесс добавления файла происходит с помощью FileUpload, т.е. выбирается файл на компьютере, добавляется описание в TextBox и по нажатию кнопки AddFile добавляется в список. При добавлении и удалении файлов происходят изменения в БД (Рис.8). Рис.8.Структура таблиц LabworkInfo,LabWork,Discipline Когда файл добавляется, у него появляется уникальный ключ – LabWorkInfoID, и данные об этом файле заносятся в соответствующие поля. 30 При нажатии на иконку удаления на какой-то определенной строке файлы удаляются по уникальному ключу и удаляются все связи с другими таблицами. Файлы представлены в списке (Рис.9), позволяющем просмотреть методическое пособие в окне браузера или загрузить к себе на компьютер. Рис.9. Список методических пособий При нажатии на название необходимого файла в правой части окна браузера появляется содержимое данного файла. Это осуществляется за счет функции AddFileToResponse, которая формирует ответ от сервера в формате html и в нем отправляется бинарный поток данных. Браузер сам распознает тип данных и открывает файл (Рис.10). 31 Рис.10. Пример отображения содержимого файла. 32 4 В основе минимизации ОПИСАНИЕ ИНТЕРФЕЙСА пользовательского количества настроек интерфейса и лежат максимально принципы дружественного внешнего вида, что исключает использование большого количества различных вариантов интерфейса. 4.1 Интерфейс преподавателя В связи с тем, что основным пользователем системы является преподаватель, то именно часть интерфейса, предназначенная для работы с этим пользователем, содержит наибольшее количество элементов. 4.1.1 Подсистема отчетности для преподавателя Преподаватель выбирает группу, предмет и нажимает на кнопку «Экспорт». На этой же странице открывается сгенерированный отчет с датой, названием предмета, фамилией преподавателя и баллами у студентов этой группы (Рис.11). Отчет можно распечатать прямо с webстраницы при нажатии на иконку принтера. 33 Рис.11.Сгенерированный отчет Отчет можно экспортировать в Excel и PDF. Формат экспортирования выбирается в специальном окошке и нажимается кнопка Export (Рис.12). Рис.12. Выбор форматов экспортирования Когда преподаватель выбирает формат экспортирования, то открывается дополнительное окно web-браузера с предложением открыть отчет, сохранить или отменить операцию экспортирования. Если этот формат PDF, то отчет открывается в программе AdobeReader (Рис.13). 34 Рис.13. Экспорт в PDF Если этот формат Excel, то сгенерированный отчет открывается в MicrosoftExcel и внутри этой программы его можно редактировать по желанию преподавателя (Рис.14). 35 Рис.14. Экспорт в Excel 4.1.2 Подсистема просмотра и редактирования методических материалов по предметам для преподавателя В соответствии с поставленной задачей был реализован функционал, позволяющий: хранить и редактировать данные о дисциплине просматривать данные о предметах на web-странице загружать доступные материалы на локальный компьютер Хранение и редактирование данных о дисциплине происходит путем добавления и удаления файлов. Добавление и удаление файлов разрешено только преподавателям, у студентов такой панели не существует, на нее поставлено условие валидации в зависимости от авторизации пользователя (Рис.15). 36 Рис.15. Добавление данных Преподаватель не может добавить пустой файл и файл с пустым описанием, так как поставлены запреты. Пример добавления файла без описания (Рис.16). Рис.16.Добавление файла без описания файла Просмотр содержимого файлов в правой части web-страницы осуществляется нажатием на название файла (Рис.17). При нажатии на кнопку Download файл сохраняется на локальный компьютер в папку c:\downloads. 37 Рис.17.Просмотр файла 4.1.3 Подсистема общей отчетности для лектора и преподавателяпрактика Подсистема общей отчетности – это электронная версия ведомости посещаемости студентов лекционных занятий. В ней указывается баллы за 2 контрольные работы, а также итоговые баллы за практические занятия, также выставляется рекомендуемая оценка с учетом всех бонусов (Рис.18). Рис.18.Ведомость подсистемы общей отчетности 4.2 Интерфейс студента Интерфейс студента значительно более простой, чем интерфейс преподавателя, что вызвано тем, что студенты не могут изменять данные в 38 ИС. Студенту стала доступна обновленная подсистема просмотра методических материалов (Рис.19) Рис.19. Подсистема просмотра методических материалов 39 ЗАКЛЮЧЕНИЕ В рамках данной дипломной работы были разработаны: подсистема отчетности, подсистема просмотра и редактирования методических материалов по предметам, подсистема общей отчетности для лектора и преподавателя практики, удовлетворяющие всем поставленным требованиям. Созданная подсистема отчетности позволяет значительно увеличить качество и удобство ведения практических лабораторных занятий в рамках рейтинговой системы ВУЗа, что особенно важно для студентов старших курсов, вечерней и заочной форм обучения. Подсистема просмотра и редактирования методических материалов по предметам позволяет пользователям получить доступ к материалам по лабораторной работе, находясь вне кафедры СПБГУАП, что особенно важно для студентов вечерней и заочной форм обучения. Подсистема общей отчетности для лектора и преподавателя практики создана для улучшения взаимодействия между практическими и лекционными занятиями и помогает выставить справедливую итоговую оценку знаний. В ходе разработки были использованы передовые технологии разработки ПО, такие как, NET Framework 3.5, ASP 2.0, MicrosoftReporting Services. Основными направлениями для дальнейшего развития ИС могут стать: Взаимодействие с ИС других кафедр 40 Внедрение ИС в глобальную ИС ВУЗа Разработка системы «Антиплагиатор» курсовых и дипломных работ 41 для лабораторных, ЛИТЕРАТУРА 1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес - GangofFour, Приемы объектно-ориентированного проектирования, паттерны проектирования – издательство Питер, 2007; 2. Мартин Фаулер, Рефакторинг, улучшение существующего кода – издательство Символ-Плюс, 2007; 3. Эрик Аллен, Типичные ошибки проектирования – издательство Питер, 2003; 4. Ричард Веймаер, MicrosoftSQLServer 2000 – издательский дом Вильямс, 2001. 5. Г. Шилдт, C# - учебный курс - издательство Питер, 2003; 6. Джеффри Рихтер, CLRviaC#: программирование на платформе .NET 2.0 на языке C# – издательство Питер, 2007; 7. Мэтью Мак-Дональд, Марио Шпушта, MicrosoftASP.NET 2.0 с примерами на C# 2005 для профессионалов – издательский дом Вильямс, 2006; 8. ДиноЭспозито, Знакомство с ASP.NET 2.0 – издательство Питер, 2006; 9. ДиноЭспозито, ASP.NET 2.0 углубленное изучение – издательство Питер, 2007; 10. О.Н. Рева, JavaScript – издательство Эксмо, 2007. 42 ПРИЛОЖЕНИЕ 1 Листинг программы визуализации методических пособий: public abstract class HandlerBase : IHttpHandler { #region IHttpHandler Members public void ProcessRequest(HttpContext context) { ProcessRequestMain(context); } public abstract bool IsReusable { get; } #endregion protected static void DisableCache(HttpContext context) { context.Response.Clear(); //say no to cache and buffers context.Response.Buffer = false; context.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches ); context.Response.Cache.SetCacheability(HttpCacheability.NoCache); context.Response.Cache.SetNoStore(); context.Response.Cache.SetNoServerCaching(); context.Response.Cache.SetExpires(DateTime.Now); } protected static void AddFileToResponse(HttpContext context, string contentType, string fileNameWithExtension, byte[] content) { AddFileToResponse(context, contentType, fileNameWithExtension, content, true); } protected static void AddFileToResponse(HttpContext context, string contentType, string fileNameWithExtension, byte[] content, bool attachment) { context.Response.AddHeader("content-disposition", String.Format("{0} filename={1}", attachment ? "attachment;" : string.Empty, fileNameWithExtension)); context.Response.ContentType = contentType; context.Response.AddHeader("content-length", content.Length.ToString()); context.Response.Flush(); if (content.Length > 0) { context.Response.BinaryWrite(content); context.Response.Flush(); } } public abstract void ProcessRequestMain(HttpContext context); } 43 public class DbFileHandler : HandlerBase { #region IHttpHandler Members public override bool IsReusable { get { return false; } } public override void ProcessRequestMain(HttpContext context) { int fileId = int.Parse(context.Request.QueryString[DbFileViewerQueryParam]); string temp = LabWorkBD.GetInfo(fileId); if (File.Exists(temp)) { using (var fs = new FileStream(temp, FileMode.Open, FileAccess.Read)) { var fileData = new byte[fs.Length]; fs.Read(fileData, 0, (int)fs.Length); AddFileToResponse(context, temp.MimeType, fs.Name, fileData, false); } } else { context.Response.Write("File not found !!!"); } } #endregion IHttpHandler Members public const string DbFileViewerFileRequest = "DbFileViewer.ashx"; public const string DbFileViewerQueryParam = "fid"; public static string DbFileViewerUrl(int fileId) { return String.Format("{0}?{1}={2}", DbFileViewerFileRequest, DbFileViewerQueryParam, fileId); } 44 ПРИЛОЖЕНИЕ 2 Техническое задание 1 Введение Подсистема отчетности, подсистема просмотра и редактирования методических материалов по предметам, и подсистема общей отчетности для лектора и преподавателя практики создается с целью ускорить работу и повысить достоверность данных при работе с оценками студентов и их посещением занятий, а также повысить качество образовательного процесса. 2 Назначение разработки Основные задачи, которые должны решать разрабатываемые системы: Повышение эффективности обучения Уменьшение времени, затрачиваемого на анализ текущей успеваемости студентов Повышение достоверности данных 3 Требования к функциональным характеристикам Системы должны представлять собой комплекс программных средств для решения поставленных задач и соответствовать следующим требованиям к функциональности: Обеспечивать доступ к данным с любого компьютера локальной сети кафедры или удаленного компьютера за пределами университета. Добавлять, удалять и редактировать успеваемости студентов и их посещении занятий. 45 сведения об Хранить и редактировать данные о предметах (такие данные, как – список рекомендуемой литературы, ссылки на учебники и т.д.). обеспечить возможность экспорта данных в формат MS Office Excel и Adobe Acrobat (PDF). 4 Требования к надежности При выборе технических средств для реализации систем и разработки ПО, необходимо учесть требования, предъявляемые к системам: Высокая степень защиты данных; Обеспечение достоверности отображаемых данных; Регистрация всей информации, циркулирующей в системе; Возможность выдачи информации на экран монитора в форме, обеспечивающей эффективную работу оператора; Обеспечение высокой надежности как технических средств, так и ПО. 5 Условия эксплуатации Системы должны быть реализованы на языке программирование высокого уровня, с использованием возможностей интерфейса веб-страниц. Клиент: процессор не хуже Pentium II 400 МГц объем ОЗУ не менее 512 Мб; монитор не хуже SVGA 0.26, 15 дюймов Клавиатура IBM PC AT 101/102 клавиши Манипулятор мышь. 46 Сервер: процессор не хуже Pentium IV 1ГГц объем ОЗУ не менее 1024 Мб объем жесткого диска не менее 10 Гб (свободно не менее 1ГБ) Сетевая карта 6 Требования к информационной и программной совместимости Вся клиентская часть систем должна быть разработана на языке C# 3.5. Часть приложения, обеспечивающая необходимую работу с СУБД, должна быть реализована на языке T-SQL, совместимым с MS SQL Server 2008. Системное программное обеспечение, требуемое для сервера ПО, включает в себя операционную систему Microsoft Windows NT или выше, сетевое программное обеспечение Microsoft, комплекс библиотек .NET Framework 3.5 Системное программное обеспечение для клиента – браузер с поддержкой технологии AJAX 7 Требования к программной документации Документация на разрабатываемые системы должна включать: руководство пользователя; руководство системного программиста. 8 Стадии и этапы разработки Период разработки разбивается на следующие стадии: 47 Разработка концептуальной модели Разработка пользовательских интерфейсов Разработка способов взаимодействия с БД Кодирование алгоритмов Отладка и тестирование При завершении кодирования каждого модуля проводится его предварительное тестирование. После окончания этапа кодирования производится сборка и финальное тестирование системы Документирование Завершающая стадия. В ней описывается функциональность и структура сохраняемых документов 48