27

Содержание

• ВВЕДЕНИЕ
• 1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ
• 1.1 Определения и особенности программированного обучения
• 1.2 Основные виды систем программированного обучения
• 1.3 Проблемы и перспективы развития систем программированного обучения
• 1.4 Постановка задачи
• 1.5 Разработка программированной структуры курса
• 1.6 Критерии эффективности и планируемые значения показателей эффективности проектируемой системы
• 1.7 Разработка информационно-логической структуры системы
• 1.7.1 Краткое описание методологии UML
• 1.7.2 Краткое описание средства разработки проекта Software Ideas Modeler
• 1.7.3 Построение модели анализа
• 1.7.4 Сценарии вариантов использования
• 1.7.5 Диаграммы классов (Class Diagram)
• 1.7.6 Диаграмма граничных классов
• 1.7.7 Диаграмма классов управления
• 1.7.8 Диаграммы состояний (Statechart Diagram)
• 1.8 Логическая структура базы данных
• 1.9.1 Оценка требуемой внешней памяти
• 1.9.2 Оценка требуемой оперативной памяти
• 1.9.3 Оценка быстродействия системы
• 2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
• 2.1 Выбор и обоснование архитектуры системы
• 2.2 Выбор средств реализации программной системы
• 2.2.1 Платформа Borland Delphi 7
• 2.2.2 Описание преимуществ
• 2.3 Описание основных алгоритмов системы
• 2.4 Разработка программного обеспечения
• 2.4.1 Компоненты системы
• 2.5 Разработка графического интерфейса пользователя
• 2.5.1 Главная страница приложения
• 2.5.2 Вкладка “Администратор”
• 2.5.4 Вкладка “Студент”
• 2.6 Разработка программы и методики испытаний
• 2.6.1 Объект испытаний
• 2.6.2 Цели испытаний
• 2.6.3 Объем и порядок проведения
• 2.6.4 Методика испытаний
• 2.6.5 Контрольный пример
• 2.7 Компьютерная безопасность и защита информации
• 2.7.1 Угрозы информационной безопасности
• 2.7.2 Закон о защите персональных данных
• 2.7.3 Защита системы от несанкционированного доступа
• 2.7.4 Защита сетевых соединений
• 2.7.5 Защита данных
• 2.7.6 Защита от вредоносных программ
• 2.7.7 Средства защиты информации в разрабатываемой информационной системе
• 2.8 Поставка и развертывание системы
• 2.8.1 Требования к программному обеспечению для запуска системы
• 2.9 Разработка руководства пользователя
• 3. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 3.1 Краткая характеристика работы и ее назначение
• 3.2 Расчет затрат на разработку информационной системы (ИС)
• 3.3 Расчет-прогноз минимальной цены разработки ИС
• 3.4 Расчет единовременных затрат на внедрение ИС
• 3.5 Расчет текущих затрат на функционирование ИС
• 3.6 Оценка безубыточности и расчет целесообразного объема продаж
• 3.7 Расчет экономической эффективности инвестиционных затрат
• 4. РАЗРАБОТКА МЕРОПРИЯТИЙ ПО БЕЗОПАСНЫМ УСЛОВИЯМ ТРУДА
• 4.1 Общие положения по безопасным условиям труда в сфере информационно-коммуникационных технологий
• 4.2 Общие требования к организации рабочих мест пользователей ПЭВМ
• 4.3 Эргономичность пользовательских интерфейсов офисных программ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ:

программированный информационный память интерфейс

ВВЕДЕНИЕ

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

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

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

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

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Определения и особенности программированного обучения

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

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

1.2 Основные виды систем программированного обучения

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

1. Линейная система программированного обучения, первоначально разработанная американским психологом Б.Скиннером [2] в начале 1960-х годов на основе бихевиористского направления в психологии. Согласно этой системе обучаемые проходят все шаги обучаемой программы последовательно в том порядке, в котором они приведены в программе. Задания в каждом шаге состоят в том, чтобы заполнить одним или несколькими словами пропуск в информационном тексте. После этого обучаемый должен сверить свое решение с правильным, которое до этого каким-либо способом было закрыто. Если ответ обучаемого оказался правильным, то он должен перейти к следующему шагу; если же его ответ не совпадает с правильным, то он должен выполнить задание еще раз Таким образом, линейная система программированного обучения основана на принципе обучения, предполагающего безошибочное выполнение заданий. Поэтому шаги программы и задания рассчитаны на наиболее слабого ученика. По мысли Скиннера, обучаемый учится в первую очередь выполняя задания, а подтверждение правильности выполнения задания служит подкреплением для стимуляции дальнейшей деятельности обучаемого.

2. Разветвленная программа программированного обучения, основоположником которой является американский педагог Н. Краудер. Контрольные задания в шагах этой системы состоят из задачи или вопроса и набора нескольких ответов, в числе которых обычно один правильный, а остальные неверные, содержащие типичные ошибки. Обучаемый должен выбрать из этого набора один ответ. Если он выбрал правильный ответ, то получает подкрепление в виде подтверждения правильности ответа и указание о переходе к следующему шагу программы. Если же он выбрал ошибочный ответ, ему разъясняется сущность допущенной ошибки и он получает указание вернуться к какому-то из предыдущих шагов программы или же перейти к некоторой подпрограмме.

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

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

Используются следующие способы ввода ответов:

1) свободное конструирование ответа из заданного набора букв, цифр, условных знаков или же формулирование его в словесной форме;

2) регламентированное кодирование ответа в форме условного знака или определенной последовательности этих знаков;

3) выборочный способ-выбор ответа из заданного набора;

4) смешанный способ.

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

1) адаптивные только к темпу работы обучаемых;

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

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

1.3 Проблемы и перспективы развития систем программированного обучения

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

Наибольшее распространение различные системы программированного обучения получили в 50-60-х годах прошлого века, в дальнейшем стали использовать лишь отдельные элементы программированного обучения в первую очередь для контроля знаний, консультаций и тренировки навыков. В последние годы идеи программированного обучения стали возрождаться на новой технической основе (ЭВМ, телевизионные системы, микрокомпьютеры и др.) в форме компьютерного или электронного обучения. Новая техническая база позволяет почти полностью автоматизировать процесс обучения, строить его как достаточно свободный диалог обучаемого с обучающей системой. Роль учителя в этом случае состоит в первую очередь в разработке, наладке, коррекции и усовершенствовании обучающей программы, а также проведении отдельных элементов безмашинного обучения. Многолетний опыт подтвердил, что программированное обучение, и особенно компьютерное, обеспечивает не только достаточно высокий уровень обучения, но и развития учащихся, вызывает у них неослабевающий интерес [3].

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

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

- вести справочную информацию, а именно: справочник групп, преподавателей и разделов программированной структуры курса;

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

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

- формировать отчёты о прохождении программированной структуры курса по каждому студенту или по студенческой группе в целом.

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

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

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

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

Работу с системой осуществляют:

- студент группы (прохождение обучения и тестирования);

- преподаватель (формирование программированной структуры курса, формирование тестов);

- администратор (ведение справочников).

1.5 Разработка программированной структуры курса

Система универсальна, и в неё можно загрузить любой курс, но в качестве контрольного примера был взят раздел изучения “Нелинейные уравнения” дисциплины “Вычислительная математика”.

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

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

Таблица 1 - Программированная структура раздела “Нелинейные уравнения” дисциплины “Вычислительная математика”

№ темы	Раздел “Нелинейные уравнения”	Входит
1	Отделение корней	лекция тест
2	Метод деления отрезка пополам	лекция тест
3	Метод хорд	лекция тест
4	Метод Ньютона (касательных)	лекция тест
5	Метод итераций	лекция тест

1.6 Критерии эффективности и планируемые значения показателей эффективности проектируемой системы

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

Для разрабатываемой информационной системы выделим следующие показатели эффективности.

Режим работы - диалоговый.

Тип архитектуры - клиент-серверное приложение

Время реакции системы:

- по запросу на ввод данных - 4с;

- для наиболее сложного запроса 30с.

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

Система должна удовлетворять СанПИН 2.2.2.4-03.

Условия работы средств вычислительной техники должны соответствовать ГОСТ 1.12.005; ГОСТ 1.12.007.

1.7 Разработка информационно-логической структуры системы

1.1.1 Краткое описание методологии UML

Разработка информационно-логической модели системы производилась на унифицированном языке моделирования UML [4].

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

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

- диаграмма вариантов использования;

- диаграмма классов;

- диаграмма состояний;

- диаграмма деятельности;

- диаграмма последовательности;

- диаграмма коопераций;

- диаграмма компонентов системы;

- диаграмма развертывания.

1.1.2 Краткое описание средства разработки проекта Software Ideas Modeler

Software Ideas Modeler - программная платформа моделирования, которая поддерживает UML (Унифицированный Язык Моделирования) [5]. Она основана на версии UML 1.4 и поддерживает нотацию UML версии 2.0 и одиннадцать различных типов диаграмм. Она активно поддерживает подход MDA (Архитектура Управляемая Моделью) и концепцию профилей UML. Software Ideas Modeler превосходен в отношении настройки окружения пользователя и имеет высокую степень расширяемости в том, что касается его функциональных возможностей.

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

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

Software Ideas Modeler - платформа моделирования программ. Преимущества расширяемой платформы:

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

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

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

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

1.1.3 Построение модели анализа

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

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

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

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

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

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

Исходя из анализа предметной области, выделим три группы пользователей: администраторы, преподаватели и студенты. Каждая роль на диаграмме вариантов использования показана в виде отдельного актанта. Каждый из актантов может выполнять различные сценарии в системе. Рассмотрим подробнее каждый из актантов и сценарии использования системы, доступные ему. Диаграмма вариантов использования системы показана на рисунке 1.

Актант “Преподаватель”

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

Актант “Администратор базы данных”

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

Актант “Студент”

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

Рисунок 1 - Диаграмма вариантов использования

1.1.4  Сценарии вариантов использования

Сценарий использования, вариант использования, прецедент (англ. Use Case) -- в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, “кто” и “что” может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.

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

Ниже приведены два наиболее наглядных сценария:

- формирование вопросов к разделу преподавателем;

- прохождение теста студентом.

1) Вариант использования. Формировать вопросы к разделу.

Краткое описание. Позволяет преподавателю формировать вопросы к разделу.

Актант. Преподаватель

Предусловия. Выполнен вариант использования “Войти в систему преподаватель”. На экране форма приложения с пунктами меню, настроенными на права преподавателя.

Основной поток событий

1. Преподаватель выбирает пункт главного меню “Формировать вопросы к разделу”.

2. Система выводит на экран форму “Формирование вопросов к разделу” с полями для ввода названия “Раздела” и количества вопросов. На форме имеются кнопки “ОК” и “Отмена”. К полю для ввода “Раздела”, подключен в виде выпадающего списка справочник разделов.

3. Преподаватель выбирает или вводит название раздела и количество вопросов, щёлкает кнопку “ОК”.

А1: Отмена операции.

А2: В выпадающем списке отсутствует название раздела.

4. Система проверяет правильность заполнения и закрывает форму “Формирование вопросов к разделу” и открывает новую форму “Создание и редактирование вопросов” с группой полей, количество которых соответствует количеству вопросов. В каждом элементе группы имеются редактируемые поля: “id вопроса” (заполняется автоинкрементно), ввода текста вопроса, ввода вариантов ответов и указания правильного ответа в форме флага. На форме расположены кнопки “Сформировать тест” и “Закрыть”.

А3: Не все поля заполнены.

А4: Поле “количество вопросов” заполненено некорректно.

5. Преподаватель заполняет группу полей для всех вопросов теста и щёлкает кнопку “Сформировать вопросы к разделу”.

А1: Отмена операции.

6. Система проверяет правильность расстановки флагов и полноту заполнения полей и выдаёт сообщение с текстом “Вы действительно хотите завершить формирование вопросов к разделу?” и двумя кнопками “ОК” и “Отмена”.

А5: Неверная расстановка флагов.

7. Преподаватель нажимает кнопку “ОК”.

А1: Отмена операции.

8. Система закрывает окно сообщения, форму ввода и редактирования вопросов и заносит данные теста в базу данных. На экране форма приложения, настроенная на права преподавателя. Вариант использования завершается успешно.

Альтернативы

А1: Отмена операции.

А1.1. Преподаватель щёлкает кнопку “Отмена”.

А1.2. Система не сохраняет данные, введённые преподавателем, закрывает форму формирования тестов и выводит на экран форму приложения, настроенную на права преподавателя. Вариант использования завершается.

А2: В выпадающем списке отсутствует название раздела.

А2.1. Преподаватель нажимает кнопку “ОК”.

А2.2. Система выводит сообщение “отсутствует название раздела, введите название или обратитесь к администратору” с кнопкой “ОК”.

А2.3. Преподаватель просматривает сообщение и щёлкает кнопку “ОК”.

А2.4. Система закрывает сообщение и возвращает преподавателя на форму “Вопросы к разделу”, и ставит курсор в поле для ввода название раздела.

А2.5. Выполняется пункт 3 основной последовательности.

А3: Не все поля заполнены.

А3.1. Система выводит сообщение “Заполнены не все поля” и возвращает преподавателя на форму формирования тестов, устанавливая курсор в первое незаполненное поле.

А3.2. Выполняется пункт 3 основной последовательности.

А4: Поле “количество вопросов” заполненено некорректно.

А4.1. Система выводит сообщение “количество вопросов заполненено некорректно” и возвращает преподавателя на форму вопросы к разделу, устанавливая курсор в некорректно заполненное поле.

А4.2. Выполняется пункт 3 основной последовательности.

А5: Неверная расстановка флагов.

А5.1. Система выводит сообщение о некорректной расстановке флагов с кнопкой “ОК”.

А5.2: Преподаватель просматривает сообщение и щёлкает кнопку “ОК”

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

А5.4. Выполняется пункт 5 основной последовательности.

2) Вариант использования. Пройти тест по разделу.

Краткое описание. Позволяет студенту проходить тестирование. Расширяет вариант использования “Обучаться по разделу”.

Актант. Студент

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

Основной поток событий

1. Студент выбирает пункт меню “Тесты”.

2. Система выводит окно со списком тестов, упорядоченным по датам создания. Список оформлен в виде выпадающего списка выбора. В окне имеются кнопки “Начать тестирование” и “Закрыть”

3. Студент выбирает нужный тест и щёлкает кнопку “Начать тестирование”

А1: Щёлкнута кнопка “Закрыть”.

4. Система выводит на экран форму прохождения теста с полем “Текст вопроса”, 4 вариантами ответа в форме переключателей и кнопками “Предыдущий вопрос”, “Следующий вопрос” и “Завершить тестирование”.

5. Студент устанавливает переключатели на все варианты ответа и щёлкает кнопку “Завершить тестирование”.

А2: Щёлкнута кнопка “Предыдущий вопрос”.

А3: Щёлкнута кнопка “Следующий вопрос”.

Система выводит окно поверх формы прохождения теста с вопросом “Вы действительно хотите завершить тестирование? “ и кнопками “Да” и “Нет”.

6. Студент щёлкает “Да”.

А4: Щёлкнута кнопка “Нет”.

7. Система закрывает окно с вопросом по завершению тестирования и выводит окно результатов тестирования поверх формы прохождения теста (процент правильных ответов) с кнопкой “ОК”.

Студент просматривает результаты тестирования и щёлкает кнопку “ОК”.

8. Система закрывает окна результатов тестирования и формы прохождения теста. На экране главная форма приложения с пунктами меню, настроенными на права студента. Вариант использования завершается успешно.

Альтернативы

А1: Щёлкнута кнопка “Закрыть”.

А1.1. Система закрывает окно с тестами и возвращает студента на форму приложения с пунктами меню, настроенными на права студента. Вариант использования завершается.

А2: Щёлкнута кнопка “Предыдущий вопрос”.

А2.1. Система отображает в форме прохождения теста текст следующего вопроса.

А2.2. Выполняется пункт 5 основной последовательности.

А3: Щёлкнута кнопка “Следующий вопрос”.

А3.1. Система отображает в форме прохождения теста текст следующего вопроса.

А3.2. Выполняется пункт 5 основной последовательности.

А4: Щёлкнута кнопка “Нет”.

А4.1. Система закрывает окно сообщения и активирует форму прохождения тестов.

А4.2. Выполняется пункт 5 основной последовательности.

Данные сценарии являются одними из основных при работе системы и обеспечивают её работоспособность.

1.1.5 Диаграммы классов (Class Diagram)

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

Диаграмма сущностных классов комплекса представлена на рисунке 2.

Рисунок 2 - Диаграмма сущностных классов

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

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

Для хранения этой информации в базе данных сущности преобразуются в объекты реляционной модели. Подробнее о структуре базы данных информационной системы рассказано в главе 1.8

1.1.6 Диаграмма граничных классов

Пользователь взаимодействует с системой через графический или другой интерфейс. Для моделирования процесса взаимодействия строится диаграмма граничных классов. Граничным классом называется класс, который находится на границы информационной системы и среды. Именно с ним происходит взаимодействие. Для проектируемой системы была разработана диаграмма граничных классов системы, она показана на рисунке 3. На диаграмме отображены все классы системы. Для конкретного актанта, в зависимости от его права доступа, могут быть не доступны некоторые страницы. При начале работы с системой пользователь взаимодействует с главной страницей. Через пункты меню пользователь может перейти к другим классам.

Краткая характеристика граничных классов:

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

- Форма формирования вопросов к разделу - позволяет пользователю формировать тесты, вопросы теста и их количество;

- Форма прохождения тестов - позволяет студенту проходить тестирование и в зависимости от результата переходить к другим разделам;

- Форма создания и редактирования вопросов - позволяет преподавателю формировать вопросы теста;

- Форма отчёта анализа усвоения для конкретного студента - позволяет преподавателю просмотреть отчёт по успеваемости каждого из студентов;

- Форма отчёта анализа успеваемости по группе - позволяет преподавателю просмотреть отчёт по успеваемости по группе в целом;

- Форма справочника дисциплин - позволяет администратору добавлять и редактировать список дисциплин;

- Форма справочника студенческих групп - позволяет администратору добавлять и редактировать список групп;

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

Рисунок 3 - Диаграмма граничных классов

1.1.7 Диаграмма классов управления

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

Рисунок 4 - Диаграмма классов управления

1.1.8 Диаграммы состояний (Statechart Diagram)

Диаграмма состояний (statechart diagram) - диаграмма, на которой изображается конечный автомат с простыми состояниями, переходами и, возможно, вложенными композитными состояниями.

В отличие от статического представления, диаграмма состояний является детализацией диаграммы вариантов использования, на логическом уровне она описывает поведение объектов системы и системы в целом. В основе диаграммы лежит понятие конечного автомата (state machine).

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

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

Начальным состоянием является отображение страницы авторизации.

В этот момент времени система переходит в состояние “Авторизация пользователя”. Основное действие в этом состоянии - проверка вводимых реквизитов пользователя. В этот момент времени система перешла в состояние “Ожидание действий пользователя”. При переходе пользователя от страницы к странице система меняет свое состояние. При успешном завершении сценария авторизации, пользователь перенаправляется на главную страницу. Состояние меняется на “Ожидание действий пользователя”.

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

Начальным состоянием является “Ожидание действий пользователя”. При переходе к странице “Освоение раздела дисциплины”, система переходит в состояние “Освоение раздела дисциплины”. При этом в начале выполняются операции по загрузке данных (учёт освоения каждым студентом). При переходе пользователя по ссылке “Ознакомление с теорией”, отображается страница с теорией по разделу дисциплины. Система переходит в состояние “Ознакомление с теорией”. Далее пользователь может перейти по ссылке “Выбор теста”. Состояния, связанные с дальнейшим освоением раздела, показаны на диаграмме.



Рисунок 5 - Диаграмма состояний системы

При выборе пункта меню “Формировать тест” система переходит в состояние “Формировать тест”. Это состояние является композитным, рассмотрим его ниже. По завершении всех действий в этом состоянии система переходит в состояние “Ожидание действий пользователя”.

Начальным состоянием является “Ожидание действий пользователя”. При переходе к странице “Формировать тест”, система переходит в состояние “Формировать тест”. При переходе пользователя по ссылке “Ввод имени теста и количества вопросов” отображается меню, где можно задать эти параметры, система при этом переходит в состояние “Формирование вопросов”. Далее пользователь может перейти к завершению формирования теста, система при этом переходит в состояние “Завершение формирования теста”. Состояния, связанные с формированием теста, показаны на диаграмме.

При выборе пункта меню “Работа с отчётами” система переходит в состояние “Работа с отчётами”. Это состояние является композитным, рассмотрим его ниже. По завершении всех действий в этом состоянии система переходит в состояние “Ожидание действий пользователя”.

Начальным состоянием является “Ожидание действий пользователя”. При переходе к странице “Работа с отчётами”, система переходит в состояние “Работа с отчётами”. При щелчке по кнопке “Запрос предмета” пользователь может выбрать из выпадающего списка дисциплину. Система переходит в состояние “Запрос предмета”. Далее пользователь выбирает необходимый вид отчёта. Состояния, связанные с дальнейшей работой с отчётами, показаны на диаграмме.

При завершении работы система переходит в финальное состояние - “Завершение работы приложения”.

1.8 Логическая структура базы данных

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

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

- Группа (id группы, название группы);

- Студент (id_студента, id_группы, имя_студента, логин_студента, пароль_студента);

- Тест (id_теста, id_раздела, id_студента, дата, сдан);

- Тест_Вопрос_Ответ (id_теста, id_вопроса, id_ответа);

- Преподаватель (id_преподавателя, ФИО_преподавателя, логин, пароль);

- Раздел (id_раздела, название_раздела);

- Раздел_Вопрос (id_раздела, id_вопроса);

- Вопрос (id_вопроса, текст_вопроса);

- Ответ (id_ответа, текст_ответа)

- Вариант ответа по разделу (id_раздела, id_вопроса, id_ответа, признак правильности).

Рисунок 6 - Логическая структура базы данных

1.9 Оценка характеристик системы

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

1.1.9 Оценка требуемой внешней памяти

Для расчета необходимой внешней памяти воспользуемся формулой:

, Мбайт (1)

где - общий объем внешней памяти;

- объем внешней памяти, требуемый для хранения файлов операционной системы и её нормальной работы;

- объем внешней памяти, требуемый для хранения файлов СУБД;

- объем внешней памяти, требуемый для хранения записей базы данных и результатов выполнения функций;

- объем внешней памяти, необходимой для хранения текстов и библиотек приложений.

Сервер

АИС устанавливается на сервер с операционной системой Microsoft Windows XP любой редакции, достаточной редакцией является Windows XP home edition. Необходимая система управления базами данных - Microsoft Аccess. Объем внешней памяти ОС и СУБД будут, соответственно равны 820 Мбайт и 418 Мбайт. Предполагается, что база будет максимально заполнена. Индексный файл принят в размере 15% от основного.

Данные расчетов сведены в таблице 2.

Таблица 2 - Расчет объема данных

Таблица БД	Размер записи, байт	Max количество записей	Размер индекса, байт	Итого, байт
Tests	1701	40	8534	76574
Theory	982	140	21704	159184
Groups	1003	1400	22346	1426546
Forms	18	1400	4174	29374
StResults	2480	1450	55725	3651725
Resources	54	1300	8934	79134
Searches	18	12	32	248
Users	1100	12	1700	14900
Roles	1400	3	800	5000
Preps	64	20	180	1460
			Итого	5316,54785Мб

Сложив полученные данные, получим:

=820+418+5317+4 6555 Мбайт, или 6,6 Гбайта.

Клиент

Считаем, что клиент работает под управлением ОС Windows XP Home Edition. Для работы ему требуется только само приложение, поэтому:

Vвп=Vос+Vпрограммы=820 + 304 =1,1Гб

1.1.10 Оценка требуемой оперативной памяти

Формула, используемая для расчета требуемой оперативной памяти, аналогична формуле (1).

По данным разработчиков имеем следующие начальные данные:

Сервер

Результаты расчета объема кэша для хранения данных в оперативной памяти приведены в таблице 3.

Таблица 3 - Расчет объема буферизации

Таблица БД	Размер записи, байт	Max количество записей	Размер индекса, байт	Итого, байт
Tests	1701	4	853	7657
Theory	982	14	2170	15918
Groups	100	550	80960	135960
Forms	18	440	1392	9312
StResults	248	1100	36345	309145
Resources	54	440	2435	26195
Searches	18	430	1115	8855
Users	1100	4	440	4840
Roles	1400	3	602	4802
Preps	64	9	35	611
			Итого	511,0303

Таким образом, окончательно, получаем:

= 820+512+50 ? 1,4 Гбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем два модуля по 1048 Мбайт, т.е. 2096 Мбайт.

Клиент

V ОС=50 Мб.

V программы=512 МБ.

Таким образом, общий объём оперативной памяти, необходимый для работы пользователей:

V озу = 50 + 512 = 562 Мб.

1.1.11 Оценка быстродействия системы

Оценку быстродействию системы должен дать расчет времени реакции системы.

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

Общее время реакции системы на выполнение запроса рассчитывается по формулам:

(2)

В формулах (2):

- время на ввод входных данных запроса;

- коэффициент ошибок при вводе, можно принять равным 1,5;

- количество символов, вводимых в качестве исходных данных;

- время ввода одного символа, при ручном вводе с клавиатуры в некоторую экранную форму можно принять равным 2с.;

- время, затрачиваемое на считывание физических блоков при работе с накопителем

- количество считываемых физических блоков, зависит от количества обрабатываемых таблиц и их объема;

- время позиционирования головок дискового накопителя;

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

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

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

- среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять равным 60;

- тактовая частота процессора, Гц;

- средний объем таблицы, байт

- количество таблиц, обрабатываемых в запросе;

- объем физического блока носителя, байт;

- время на вывод результата на устройство вывода или отображения, для принтера оценивается отдельно. Для дисплея можно принять 0,5 с.

Для расчета возьмем случай просмотр отчета о результатах успеваемости группы. Отчет строится по 4 таблицам, и средний объем выборки данных составляет 1 мегабайт. В среднем просматривается половина записей. Примем стандартный размер физического блока за 512 байт, и произведем расчет:

Таблица 4 - Расчет времени реакции системы

Параметры	Значения
Nтабл=	4
Vтабл=	1048576
Nбл=	4096
tввода=	3
tсчитыв=	12,288
tвычисл=	0,000075
tреакции=	15,788075

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

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

- к серверу: процессор класса Intel Core 2 Duo или Intel Core 2 Quad с тактовой частотой не менее 2,3 ГГц на каждое ядро, минимальный объем оперативного запоминающего устройства (ОЗУ) - 1024 Мбайт, жесткий диск ёмкостью не менее 10 Гбайт;

- к клиенту: процессор класса Intel Core 2 Duo с тактовой частотой не менее 2 ГГц на каждое ядро, минимальный объем оперативного запоминающего устройства (ОЗУ) - 1024 Мбайт, жесткий диск ёмкостью не менее 1,1 Гбайт.

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Выбор и обоснование архитектуры системы

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

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

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

- что делает система?

- на какие части она разделяется?

- где эти части размещены?

- как эти части взаимодействуют?

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

Выбор архитектуры производился из трёх основных типов:

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

- клиент-серверная трехзвенная (частный случай multi-tier) - этот тип характеризуется наличием, кроме вышеперечисленных, промежуточного, третьего звена - сервера приложений. В этом случае, клиентские приложения не будут обращаться к СУБД напрямую - они будут взаимодействовать с промежуточным звеном;

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

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

К преимуществам трехзвенной клиент-серверной архитектуры можно отнести:

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

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

- масштабируемость - это способность системы адаптироваться к росту количества пользователей и объема базы данных при адекватном повышении производительности аппаратной платформы, без замены программного обеспечения. При наличии мощной аппаратной платформы, число пользователей может исчисляться тысячами, а размеры базы данных - десятками гигабайт [6].

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

2.2 Выбор средств реализации программной системы

При выборе средств разработки системы такого рода, необходимо выбрать такие средства, при которых разработка была бы эффективной и базировалась на современных информационных технологиях. Разработка должна вестись с использованием многофункциональной платформы. В качестве такой платформы была выбрана Borland Delphi 7 [7].

2.2.1 Платформа Borland Delphi 7

Delphi, --интегрированная среда разработки ПО для Microsoft Windows на языке Delphi (ранее носившем название Object Pascal), созданная первоначально фирмой Borland и на данный момент принадлежащая и разрабатываемая Embarcadero Technologies. Embarcadero Delphi является частью пакета Embarcadero RAD Studio и поставляется в четырёх редакциях: Starter, Professional, Enterprise и Architect. Координирующий офис Embarcadero ответственный за разработку Delphi находится в Торонто, тогда как сама разработка сконцентрирована главным образом в Румынии и России.

2.2.2 Описание преимуществ

Delphi 7 относится к классу инструментальных средств ускоренной разработки программ (RapidApplication Development, RAD). Визуальное конструирование форм Delphi избавляет от многих аспектов разработки интерфейса программы, так как уже готовы необходимые программные заготовки и соответствующие файлы ресурсов. Все компоненты характеризуются важным свойством: они включают в себя программный код и все необходимые для его работы данные. Это не только значительно ускоряет процесс написания программ, но и существенно снижает вероятность случайный программных ошибок.

Синтаксис С++ прямо-таки провоцирует создание запутанных программ, в которых трудно разобраться даже автору, в то время как простой и ясный синтаксис Delphi позволяет последнему претендовать на роль языка, идеально подходящего для описания алгоритма (недаром Паскаль происходит от использующегося для этих целей алгоритмического языка АЛГОЛ-60).

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

Наиболее приспособленным для работы с Delphi является СУБД Paradox.

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

...