Определение Требований



Скачать 370.82 Kb.
Дата05.09.2014
Размер370.82 Kb.
ТипОтчет

Оглавление


Перечень принятых сокращений 3

Введение 4

1Определение Требований 5

1.1Предметная область 5

1.2Постановка задачи 5

1.3Анализ предметной области 6

1.4Определение требований к программным подсистемам 7

2Проектирование подсистем 9

2.1Анализ модифицируемой системы 9

2.2Выбор жизненного цикла разработки системы 10

2.3Выбор модели проектирования 14

2.4Решения по комплексу технических средств 15

2.5Выбор программных средств 17

2.6C# 3.5, ASP.NET 21

2.7MSSQL 2008Express 21

2.8Итоговые требования, предъявляемые к выбору ПО 22

3Архитектура разрабатываемых подсистем 24

3.1Описание и модель подсистемы отчетности, общее описание принципов функционирования 24

3.2Описание модели подсистемы методических пособий 27

4Описание интерфейса 31

4.1Интерфейс преподавателя 31

4.1.1Подсистема отчетности для преподавателя 31

Отчет можно экспортировать в Excel и PDF. Формат экспортирования выбирается в специальном окошке и нажимается кнопка Export (Рис.12). 32

4.1.2Подсистема просмотра и редактирования методических материалов по предметам для преподавателя 34

4.1.3Подсистема общей отчетности для лектора и преподавателя-практика 36

4.2Интерфейс студента 37



ЗАКЛЮЧЕНИЕ 38

ЛИТЕРАТУРА 40

ПРИЛОЖЕНИЕ 1 41

ПРИЛОЖЕНИЕ 2 43

Перечень принятых сокращений

БД — база данных

ВУЗ — высшее учебное заведение

Гб — гигабайт

ЖЦ — жизненный цикл

ИС — информационная система

Мб — мегабайт

ОС — операционная система

ОЗУ — оперативное запоминающее устройство (оперативная память)

ПО — программное обеспечение

ПЭВМ — персональная ЭВМ

СУБД — система управления базами данных

СПБГУАП – Санкт-Петербургский государственный университет аэрокосмического приборостроения

ТЗ — техническое задание

ЭВМ — электронная вычислительная машина
Введение

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

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

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


1Определение Требований



1.1Предметная область


Рассматриваемая предметная область – рейтинговая система оценки успеваемости студентов на кафедре СПБГУАП.

1.2Постановка задачи


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

  1. Подсистему отчетности позволяющую:

  • Просматривать и распечатывать ведомость об успеваемости студентов

  • Обеспечить возможность экспорта данных в традиционные форматы Excel и PDF

  1. Подсистему просмотра и редактирования методических материалов по предметам, позволяющую:

  • Хранить и редактировать данные о дисциплине (список рекомендуемой литературы, методические пособия и т.д.)

  • Просматривать данные о предметах на web-странице

  • Загружать доступные материалы на локальный компьютер

  1. Подсистему общей отчетности для лектора и преподавателя практики, позволяющую:

  • Учитывать успеваемость студентов на всех типах занятий

  • Вывести итоговую оценку

Для выполнения поставленных задач необходимо:

  • Провести анализ созданного проекта

  • Определить программные средства для реализации создаваемых систем

  • Разработать интерфейс взаимодействия пользователя с системой


1.3Анализ предметной области


На основе описания предметной области и поставленной задачи проводится анализ предметной области с целью выявления:

  • Пользователей системы

  • Недостатков системы и способов их устранения

  • Ограничений для разных групп пользователей

Из описания предметной области можно выделить несколько ролей для внешних пользователей системы:



  • Студент – лицо, которое может просматривать информацию о своей текущей успеваемости, данных о предмете.

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

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

Для данного проекта подсистема отчетности существовала в виде htmlстраницы, что являлось существенным недостатком, так как подобное представление не поддается стандартизированному форматированию, может отличаться в разных браузерах и требует сложной последовательности действий для дальнейшей аналитической обработки. В связи с этим, возникла необходимость нового подхода к генерации отчетности, позволяющего заполнять отчеты имеющимися данными по заданному формату (PDF) и возможностью экспорта в Excel для дальнейшей обработки в случае необходимости. Также в проекте существовала страница методических пособий по лабораторным работам, но она имела ограниченную функциональность, так как отсутствовала возможность просмотра пособий вне кафедры. Необходимость в доступе к пособиям с любого компьютера, подключенного к интернету для студентов вечернего и заочного отделений, и просмотр этих данных, повлекли за собой решение усовершенствовать систему методических пособий и расширить ее применение.


1.4Определение требований к программным подсистемам


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

Подсистема отчетности должна быть:



  • универсальной,

  • простой в использовании,

  • наиболее подходящей для разработки в существующем проекте.

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

Разработка системы методических пособий по лабораторным работам должна заключаться в том, чтобы обеспечить возможность:



  • просмотра данных;

  • добавления методических пособий и дополнительных материалов;

  • удаления невостребованных данных.

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

Проектирование необходимых нам систем включает в себя следующие этапы:



  • Определение предметной области

  • Проектирование систем

  • Реализация систем


2Проектирование подсистем



2.1Анализ модифицируемой системы


Информационная система LabTracker позволила значительно увеличить качество и удобство ведения практических лабораторных занятий в рамках рейтинговой системой ВУЗа. В настоящее время в системе реализован web-интерфейс пользователей, разделенный на 3группы: преподаватели, студенты, администраторы.

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

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

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


2.2Выбор жизненного цикла разработки системы

Одним из базовых понятий методологии проектирования информационных систем является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:



  • каскадная модель (70-85 г.г.);

  • спиральная модель (86-90 г.г.).

В изначально существовавших однородных информационных системах каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит, только после того, как будет полностью завершена работа на текущем этапе (Рис.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

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






image336

Рис. 1. Каскадная модель ЖЦ


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

Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (Рис.2), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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






Рис. 2. Спиральная модель ЖЦ

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




2.3Выбор модели проектирования

Методы, используемые при проектировании программных систем можно условно разделить на три большие группы:



  • метод структурного проектирования сверху вниз;

  • метод потоков данных;

  • объектно-ориентированное проектирование.

В 60-70-е годы было разработано много методов, помогающих справится с растущей сложностью программ. Наибольшее распространение получило структурное проектирование по методу сверху вниз. Метод был непосредственно основан на топологии традиционных языков высоко уровня типа FORTRAN или COBOL. В этих языках основной базовой единицей является подпрограмма, и программа в целом принимает форму дерева, в котором одни подпрограммы в процессе работы вызывают другие подпрограммы. Структурное программирование использует именно такой подход: алгоритмическая декомпозиция применяется для разбиения большой задачи на более мелкие. Необходимо отметить, что большинство существующих программ написано, по-видимому, в соответствии с этим методом. Тем не менее, структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный подход не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектно-ориентированных языках программирования.2

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

Объектно-ориентированное проектирование (object-oriented design, OOD) – это подход, в основу которого положено представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию. Объектно-ориентированный подход отражает топологию языков высокого уровня, таких как Delphi, C++ и C#.

Общая концепция ИС предполагает реализацию совокупности объектов и их взаимодействие, поэтому реализацию системы было решено создавать на базе объектно-ориентированного подхода с применением языка высокого уровня C# 3.5.



2.4Решения по комплексу технических средств

Среди всего множества критериев отбора технических средств нас интересуют:



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

  • достаточный объем накопителя на жестком магнитном диске сервера;

  • приемлемый тип видеоадаптера и дисплея для работы пользователя;

  • достаточная производительность центрального процессора сервера;

  • наличие возможности вывода информации на бумажный, магнитный носитель;

  • достаточная скорость передачи данных в локальной сети;

  • приемлемая стоимость составляющих комплекса технических средств.

Объем необходимого ОЗУ рассчитывается, исходя из размеров памяти, занимаемой загружаемой операционной системой, из необходимого объема памяти, выделяемого под драйверы для обслуживания ЭВМ, программы-оболочки, основного загружаемого модуля программного комплекса, динамических библиотек, подгружаемых по мере выполнения программы и резерва памяти для обработки информации.

Исходя из вышеизложенного, приходим, что для нормальной работы системы необходимо не менее 1024 Мбайт ОЗУ. По современным понятиям, это уже не слишком высокое требование объясняется тем, что для нормальной работы, выбранной в качестве рекомендуемой ОС системы WindowsXP необходимо не менее 512 Мбайт оперативной памяти.

Подбор объема накопителя на жестком магнитном диске, далее HDD основывается на размере обрабатываемых данных, в момент предполагаемой пиковой загруженности, занимаемом ОС объемом жесткого диска, а также на размере архивов создаваемых системой за прошлые годы. Так же следует учесть необходимое быстродействие HDD, в зависимости от потребности в скорости реакции системы.

Предполагаемый срок службы техники – 5 лет. Так как 5 лет – средний срок полного морального устаревания парка машин и его замены.

Скорость передачи данных в ЛВС зависит от выбранного сетевого программного и технического обеспечения. Парк применяемых машин на предприятии заказчика оснащен Ethernet-адаптерами и прочими сетевыми устройствами со скоростью передачи данных 100Mбит/сек. Учитывая достаточность этой скорости для работы системы, принято решение использовать имеющиеся средства.

 Итак, подведем итоги выше приведенных рассуждений и выдвинем комплексные требования к составу технических средств, необходимых для функционирования системы.


Сервер (минимальные требования):

  • процессор не хуже PentiumIV 1ГГц

  • объем ОЗУ не менее 1024 Мб

  • объем жесткого диска не менее 10 Гб(свободно не менее 1ГБ)

  • Сетевая карта

Клиент:

  • процессор не хуже PentiumII400 МГц

  • объем ОЗУ не менее 512Мб;

  • графический адаптер не хуже SVGA16Мб;

  • монитор не хуже SVGA 0.26, 15 дюймов

  • сетевая карта


2.5Выбор программных средств


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

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

При выборе средства программирования и генерации отчетов необходимо определить основные требования:


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

  • Экспорт в различные форматы – позволяет расширить возможности отчетности

  • Печать отчетов

  • Стоимость – крайне важный параметр при ограниченном бюджете ВУЗа.

В таблице 1 дана сравнительная характеристика всех выбранных для анализа генераторов отчетов.

Таблица 1






Fast-Report.Net

Crystal Reporting

Microsoft Reporting Services

Open XML

Excel+ database

Внешний/встроенный

внешний

внешний

встроенный

встроенный

встроенный

Экспорт

есть

есть

есть

нет

нет

Печать

есть

есть

есть

нет

есть

Стоимость

высокая

высокая

бесплатно

бесплатно

высокая

При просмотре Таблицы 1 можно сделать вывод, что оптимальным программным средством для разрабатываемой системы отчетности являетсяMicrosoftReportingServices. Данный компонент является встроенным в VisualStudio 2008, он поставляется в комплекте с SQLServer, который предоставлен в бесплатной Express-версии, соответственно тоже является бесплатным, он предоставляет возможность экспортирования данных в Excel и PDF, печать сформированных отчетов.

ReportingServices включает графическую оболочку для создания отчетов - ReportDesigner, которая использует интегрированную среду разработки VisualStudio .NET и позволяет обойтись без написания кода.

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

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

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

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


  • AJAX

  • ASP.NET

  • LINQ

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


2.6C# 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.7MSSQL 2008Express


Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием 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 и выше

  • MicrosoftReportingServices

Для клиента:

  • Windows XP и выше

  • Браузер Internet Explorer

  • Adobe Acrobat Reader

  • Microsoft Office



3Архитектура разрабатываемых подсистем



3.1Описание и модель подсистемы отчетности, общее описание принципов функционирования


Существующая система разработана с использованием архитектуры клиент-сервер (рис. 3), когда между клиентом и ядром системы присутствуют посредники в виде web-браузера и web-сервера.







Рис.3. Архитектура системы

Разрабатываемая подсистема отчетности должна удовлетворять данным требованиям. Создаваемая подсистема взаимодействует с БД при помощи запросов, написанных на языке C# с использованием LINQ. Основой взаимодействия между системой и БД являются хранимые процедуры, написанные на языке SQL.

Для простоты использования и повышения защищенности приложения основные интерфейсы и сервисы взаимодействия между системой и БД вынесены в отдельную сборку LabTracker.Framework.dll.

Использование MicrosoftReportingServices предполагает работу с простыми типами данных, но информация необходимая для отчетов находится в классах. Поэтому нужно было перевести данные в простые типы. Для этого были написаны дополнительные функции MapDiscipline и MapScore, которые позволили использовать выбранные данные для отчетов. Количество лабораторных работ устанавливается автоматически при проверке ID дисциплины. Список студентов получается тоже автоматически при вводе ID группы и ID дисциплины и записывается в соответствующую графу. Также в отчете использованы такие поля как Bonus, SummaryScore, LabName и MaxBalls.

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

Процесс создания отчета происходит в дизайнере MicrosoftReportingServices (Рис.4) – данный продукт поддерживает следующие основные типы отчетов:


  • табличный - фиксированное количество столбцов;

  • матричный - количество столбцов зависит от результата запроса;

  • графический - данные представлены графически;

  • свободная форма - данные на странице организованы в произвольном виде.

Рис.4. Дизайнер MicrosoftReportingServices

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

Готовый отчет (Рис.5), например группы 4736 по ООП, можно увидеть в Internet Explorer, при нажатии на кнопку «Экспорт», и распечатать.



Рис.5. Пример готового отчета

Аналогичным способом составляется отчет о посещаемости студентов на лекционных занятиях. В отчете по лекциям содержится таблица с посещаемостью на определенный день, контрольная работа 1 и 2, итоговые баллы по практическим занятиям, суммарные баллы и рекомендованная оценка (Рис.6.).

Рис.6.Отчет посещаемости студентов


3.2Описание модели подсистемы методических пособий


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

labworkinfo

Рис.7. Информация о лабораторной работе

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

Процесс добавления файла происходит с помощью FileUpload, т.е. выбирается файл на компьютере, добавляется описание в TextBox и по нажатию кнопки AddFile добавляется в список. При добавлении и удалении файлов происходят изменения в БД (Рис.8).



Рис.8.Структура таблиц LabworkInfo,LabWork,Discipline

Когда файл добавляется, у него появляется уникальный ключ – LabWorkInfoID, и данные об этом файле заносятся в соответствующие поля.

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

Файлы представлены в списке (Рис.9), позволяющем просмотреть методическое пособие в окне браузера или загрузить к себе на компьютер.

Рис.9. Список методических пособий

При нажатии на название необходимого файла в правой части окна браузера появляется содержимое данного файла. Это осуществляется за счет функции AddFileToResponse, которая формирует ответ от сервера в формате html и в нем отправляется бинарный поток данных. Браузер сам распознает тип данных и открывает файл (Рис.10).

Рис.10. Пример отображения содержимого файла.


4Описание интерфейса


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

4.1Интерфейс преподавателя


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

4.1.1Подсистема отчетности для преподавателя


Преподаватель выбирает группу, предмет и нажимает на кнопку «Экспорт». На этой же странице открывается сгенерированный отчет с датой, названием предмета, фамилией преподавателя и баллами у студентов этой группы (Рис.11). Отчет можно распечатать прямо с web-страницы при нажатии на иконку принтера.

Рис.11.Сгенерированный отчет


Отчет можно экспортировать в Excel и PDF. Формат экспортирования выбирается в специальном окошке и нажимается кнопка Export (Рис.12).


Рис.12. Выбор форматов экспортирования

Когда преподаватель выбирает формат экспортирования, то открывается дополнительное окно web-браузера с предложением открыть отчет, сохранить или отменить операцию экспортирования. Если этот формат PDF, то отчет открывается в программе AdobeReader (Рис.13).

Рис.13. Экспорт в PDF

Если этот формат Excel, то сгенерированный отчет открывается в MicrosoftExcel и внутри этой программы его можно редактировать по желанию преподавателя (Рис.14).

Рис.14. Экспорт в Excel


4.1.2Подсистема просмотра и редактирования методических материалов по предметам для преподавателя


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

  • хранить и редактировать данные о дисциплине

  • просматривать данные о предметах на web-странице

  • загружать доступные материалы на локальный компьютер

Хранение и редактирование данных о дисциплине происходит путем добавления и удаления файлов.

Добавление и удаление файлов разрешено только преподавателям, у студентов такой панели не существует, на нее поставлено условие валидации в зависимости от авторизации пользователя (Рис.15).



Рис.15. Добавление данных

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

Рис.16.Добавление файла без описания файла

Просмотр содержимого файлов в правой части web-страницы осуществляется нажатием на название файла (Рис.17). При нажатии на кнопку Download файл сохраняется на локальный компьютер в папку c:\downloads.

Рис.17.Просмотр файла


4.1.3Подсистема общей отчетности для лектора и преподавателя-практика


Подсистема общей отчетности – это электронная версия ведомости посещаемости студентов лекционных занятий. В ней указывается баллы за 2 контрольные работы, а также итоговые баллы за практические занятия, также выставляется рекомендуемая оценка с учетом всех бонусов (Рис.18).

Рис.18.Ведомость подсистемы общей отчетности


4.2Интерфейс студента


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

Рис.19. Подсистема просмотра методических материалов


ЗАКЛЮЧЕНИЕ


В рамках данной дипломной работы были разработаны:

  • подсистема отчетности,

  • подсистема просмотра и редактирования методических материалов по предметам,

  • подсистема общей отчетности для лектора и преподавателя практики,

удовлетворяющие всем поставленным требованиям.

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

Подсистема просмотра и редактирования методических материалов по предметам позволяет пользователям получить доступ к материалам по лабораторной работе, находясь вне кафедры СПБГУАП, что особенно важно для студентов вечерней и заочной форм обучения.

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

В ходе разработки были использованы передовые технологии разработки ПО, такие как, NET Framework 3.5, ASP 2.0, MicrosoftReporting Services.

Основными направлениями для дальнейшего развития ИС могут стать:



  • Взаимодействие с ИС других кафедр

  • Внедрение ИС в глобальную ИС ВУЗа

  • Разработка системы «Антиплагиатор» для лабораторных, курсовых и дипломных работ


ЛИТЕРАТУРА




  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.






ПРИЛОЖЕНИЕ 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);

}

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);



}

ПРИЛОЖЕНИЕ 2


Техническое задание

  1. Введение

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

  1. Назначение разработки

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

  • Повышение эффективности обучения

  • Уменьшение времени, затрачиваемого на анализ текущей успеваемости студентов

  • Повышение достоверности данных

  1. Требования к функциональным характеристикам

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

  • Обеспечивать доступ к данным с любого компьютера локальной сети кафедры или удаленного компьютера за пределами университета.

  • Добавлять, удалять и редактировать сведения об успеваемости студентов и их посещении занятий.

  • Хранить и редактировать данные о предметах (такие данные, как – список рекомендуемой литературы, ссылки на учебники и т.д.).

  • обеспечить возможность экспорта данных в формат MS Office Excel и Adobe Acrobat (PDF).

  1. Требования к надежности

При выборе технических средств для реализации систем и разработки ПО, необходимо учесть требования, предъявляемые к системам:

  • Высокая степень защиты данных;

  • Обеспечение достоверности отображаемых данных;

  • Регистрация всей информации, циркулирующей в системе;

  • Возможность выдачи информации на экран монитора в форме, обеспечивающей эффективную работу оператора;

  • Обеспечение высокой надежности как технических средств, так и ПО.




  1. Условия эксплуатации

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

Клиент:


  • процессор не хуже Pentium II 400 МГц

  • объем ОЗУ не менее 512 Мб;

  • монитор не хуже SVGA 0.26, 15 дюймов

Клавиатура IBM PC AT 101/102 клавиши

Манипулятор мышь.

Сервер:


  • процессор не хуже Pentium IV 1ГГц

  • объем ОЗУ не менее 1024 Мб

  • объем жесткого диска не менее 10 Гб (свободно не менее 1ГБ)

  • Сетевая карта

  1. Требования к информационной и программной совместимости

Вся клиентская часть систем должна быть разработана на языке C# 3.5.

Часть приложения, обеспечивающая необходимую работу с СУБД, должна быть реализована на языке T-SQL, совместимым с MS SQL Server 2008.

Системное программное обеспечение, требуемое для сервера ПО, включает в себя операционную систему Microsoft Windows NT или выше, сетевое программное обеспечение Microsoft, комплекс библиотек .NET Framework 3.5

Системное программное обеспечение для клиента – браузер с поддержкой технологии AJAX



  1. Требования к программной документации

Документация на разрабатываемые системы должна включать:

  • руководство пользователя;

  • руководство системного программиста.

  1. Стадии и этапы разработки

Период разработки разбивается на следующие стадии:

  1. Разработка концептуальной модели

  2. Разработка пользовательских интерфейсов

  3. Разработка способов взаимодействия с БД

  4. Кодирование алгоритмов

  5. Отладка и тестирование

  6. При завершении кодирования каждого модуля проводится его предварительное тестирование. После окончания этапа кодирования производится сборка и финальное тестирование системы

  7. Документирование

  8. Завершающая стадия. В ней описывается функциональность и структура сохраняемых документов



1 http://www.studfiles.ru/dir/cat32/subj1340/file14246/view142176.html

2 http://www.helloworld.ru/texts/comp/other/oop/ch01.htm

3 http://www.interface.ru/home.asp?artId=968

Похожие:

Определение Требований iconОпределение ск по гражданским делам Верховного Суда РФ от 28 мая 2010 г. N 18-В10-16
Л. В. на решение Ленинского районного суда г. Краснодара от 27 августа 2009 г и определение судебной коллегии по гражданским делам...
Определение Требований iconМоя будущая профессия
Цель: определение профессиональных предпочтений. Раскрытие требований, предъявляемых профессией к личности. Ознакомление с профессией...
Определение Требований iconWww. Хелпинвер. Рф бриф на флеш-баннер
Главная задача брифа – определение пожеланий и требований заказчика, предъявляемых к его баннеру. (Поля заполняются Заказчиком по...
Определение Требований iconПисьмо Министерства образования и науки РФ от 24 января 2008 г. N ик-137/03 "О перечне государственных требований к минимуму содержания и уровню требований к специалистам для получения дополнительных квалификаций на 31 декабря 2007 года"
Нтября 2000 г. N 2571, зарегистрированным Минюстом России 24 октября 2000 г. N 2424, Минобрнауки России направляет для использования...
Определение Требований icon10-Анализ требований к аис
Разумеется, ведь в нём сосредоточено развёрнутое описание основных требований к автоматизированной информационной системе, которую...
Определение Требований iconЗарегистрировано в Минюсте РФ 9 февраля 2012 г. Регистрационный n 23191
Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра
Определение Требований iconВерификация программных требований к по. Инструменты автоматизации этапа
По и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня; 8
Определение Требований iconПояснительная записка к первой редакции проекта гост р "Информационная технология. Профиль прикладной среды организации вычислений на супер-эвм (pse10-hip)"
Целью разработки гост р является определение набора стандартов и технических требований, обеспечивающих необходимую мобильность
Определение Требований iconОпределение и свойства предела последовательности. Определение
Определение: задать числовую последовательность – это значит сопоставить каждому номеру действительное число
Определение Требований iconO услуги и продукты конкурирующих компаний сотовой связи
Необходимо соблюдение технических требований к приложениям, разработанным для операционных систем Android, Symbian,Java (ссылки на...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org