Автоматизированная информационная подсистема составления расписания экзаменационной сессии

Анализ организационных процессов учебно-методического управления, связанных с составлением расписания экзаменационной сессии. Разработка технических требований к подсистеме. Изучение информационных потоков автоматизированной информационной подсистемы.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 08.05.2017
Размер файла 1,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Для этого построим следующие диаграммы:

ѕ вариантов использования (Use Case);

ѕ действий (Activity diagram);

ѕ последовательности (Sequence diagram);

ѕ коопераций (Collaboration diagram).

Все диаграммы построим с помощью программного продукта Rational Rose - популярного средства визуального моделирования объектно-ориентированных информационных систем, основанного на универсальном языке моделирования UML.

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

· определить общие границы и контекст моделируемой предметной области;

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

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

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

Суть диаграммы вариантов использования состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Диаграмма вариантов использования может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов.[9]

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

Рисунок 6 - Use-case диаграмма "Пользователь"

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

Рисунок 7 - Use-case диаграмма "Инженер-разработчик"

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

Рисунок 8 - Use-case диаграмма "Система"

  • 2.4 Диаграмма действий
      • Диаграмма действий - это диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов -- вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла к входам другого.[9]
      • На рисунке 9 представлена диаграмма действий, проходящих в системе.
      • Рисунок 9 - Диаграмма действий
      • 2.3 Диаграмма последовательности
      • Диаграмма последовательности - это диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.
      • На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.[10]

Расшифровка действий на диаграммах:

· viewRaspisanie () - отображение расписания;

· formRaspisanie () - формирование расписания;

· makeTheRequest () - формирование запроса ;

· showResult () - показать подобранные результаты для сформированного запроса;

· seeRaspisanie () - просмотр расписания;

· selectDannie () -выбор данных;

· changeRaspisanie () - изменение расписания;

· viewResult () -просмотр результата;

· changePass () - изменить пароль;

· changeInf () - изменить данные (информацию).

Диаграммы последовательностей представлены на рисунках 10,11.

Рисунок 10 - Диаграмма последовательности работы с подсистемой

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

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

Понятие кооперации (collaboration) является одним из фундаментальных понятий в языке UML. Оно служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.[9]

Кооперация может быть представлена на двух уровнях:

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

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

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

Ниже представлены диаграммы коопераций (Рисунок 12,13).

Рисунок 12 - Диаграмма кооперации работы с подсистемой

Рисунок 13 - Диаграмма кооперации внесения изменений в подсистему

  • 3. Разработка базы данных

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой называется универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято.[10]

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

Проанализировав предметную область, выделив все реквизиты, обозначив ключи, мы пришли к тому, что получили 9 информационных объектов - сущностей: "Кафедра", "Корпус", "Группы", "Преподаватель", "Дисциплины", "Аудитория", "Время", " Дата", "Расписание".

Описание сущностей и их атрибутов представлены в таблице 2.

Таблица 2 - Описание сущностей и их атрибутов

Информационные объекты

(сущности)

Атрибуты

Кафедра (Kafedra)

ID кафедра (ID_kaf) - PK

naz_kaf - название кафедры;

zaf_kaf - заведующий кафедрой;

kr_naz - краткое название.

Корпус (Korpys)

ID корпус (ID_korp) - PK

nazv_korp - название кафедры;

sp_ayd - список айдиторий.

Группа (Grouppa)

ID группа (ID_group) - PK

ID_disc - (FK)

nom_group - номер группы;

spec - специальность;

forma_ob - форма обучения;

zach_kn - зачётная книжка;

kyrs - курс.

Преподаватели (Prepodavateli)

ID преподаватель (ID_prep) - PK

ID_kaf - (FK)

FIO - ФИО преподавателя;

shtatn_sost - штатный состав;

vid_deyat - вид деятельности;

dolzhnost - должность;

pol - пол;

ych_step - ученая степень;

ych_zv - ученое звание;

address - адрес;

telephone - телефон.

Дисциплина (Disciplina)

ID дисциплина (ID_disc) - PK

nazv_disc - название дисциплины;

component - компонент дисциплины;

spec - специальность;

forma_ob - форма обучения;

chasi - аудиторные часы;

form_ych - форма успеваемости;

vid_nagr - вид нагрузки.

Аудитория (Ayditoriya)

ID аудитория (ID_ayd) - PK

ID_korp - (FK)

nom_ayd - номер аудитории;

naznach - назначение;

kol_mest - количество мест;

kol_komp - количество компьютеров.

Время (Vremya)

ID время (ID_vrem) - PK

vr_nach - время начала;

vrem_kons - время консультации;

vrem_exm - время экзамена.

Дата (Data)

ID дата (ID_data) - PK

d_nach - дата начала сессии;

d_okonch - дата окончания сессии;

interval - интервал;

den_ned - день недели;

d_nerab - нерабочий день;

prichina - причина.

Расписание (Raspisanie)

ID расписание (ID_Raspisanie) - PK

ID_prep (FK)

ID_group (FK)

ID_data (FK)

ID_vrem (FK)

ID_ayd (FK)

nazv_disc - название дисциплины;

nazv_corp - название корпуса;

nazv_kaf - название кафедры;

pozhelaniya - пожелания.

При построении ER - модели присваивается каждой сущности свое уникальное имя (идентификатор).

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

Существует несколько видов связей:

· многие - ко - многим;

· один - ко - многим;

· один - к - одному.

Графическое изображение связей представлены на рисунке 14.

Размещено на http://www.allbest.ru/

Рисунок 14 - Графическое изображение связей

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

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

Проектирование базы данных в нотации IDEF1X представлено на рисунке 15.

Рисунок 15 - Схема базы данных в нотации IDEF1X

  • 4. Разработка модулей подсистемы "Расписание экзаменационной сессии"
    • Для реализации поставленной задачи на основе технологии Lotus Notes/Domino была создана подсистема "Расписание экзаменационной сессии", предназначенная для создания, редактирования, хранения и обработки информации, представленной в виде документов и программных модулей функций, реализующих работу подразделения.
    • БД Notes физически существует в виде дискового файла, имеющего определенную структуру.
    • Для подсистемы был выбран стандартный в рамках КИС РГУИТП пользовательский интерфейс (дизайн "Рабочего места" Пользователя).
    • Средствами Lotus Domino Designer в БД были созданы необходимые элементы дизайна БД, а именно: наборы представлений, форм и агентов, реализующих функциональные возможности, соответствующие заявленным требованиям и обеспечивающие взаимодействие пользователей с БД.[11]
    • Формы предназначены для ввода, чтения, редактирования и печати информации, представленной в виде документов. Форма может содержать множество различных элементов дизайна, таких, как:
    • · поля;
    • · надписи;
    • · графические изображения;
    • · кнопки;
    • · действия (акции);
    • · внедрённые объекты.
    • Основным элементом формы является "поле" - поименованный фрагмент вводимой, хранящейся и отображаемой информации документа. При заполнении полей формы и его сохранении, информация сохраняется в виде документа. При открытии пользователем документа, форма используется в качестве шаблона для отображения хранимой информации. Следует отметить, что один и тот же документ, при необходимости, может быть отображён с помощью разных форм. Форма не является обязательным элементом дизайна БД.
    • Подформа - это набор элементов формы, которые хранятся как отдельный объект. Подформа может быть постоянной частью формы или может появиться условно, в зависимости от результата формулы. Когда изменяется поле подформы, все формы и документы, использующие данную подформу, обновляются. Подформа также не является обязательным элементом дизайна БД.
    • Представления (виды) - это категоризированные (отсортированные по определённому признаку) списки документов. Представления являются точками доступа к документам, хранимым в БД. В БД данных должно иметься по крайней мере одно представление, хотя большинство БД содержат несколько представлений, по-разному представляющих ее содержание и, соответственно, дающих различные возможности для работы с информацией.
    • Агент - элемент дизайна БД (Программный модуль), предназначенный для автоматизации различных действий: модификации полей документов, отправка почтовых сообщений, поиск информации и т.п.
    • Для реализации функционирования подсистемы были разработаны формы, список которых представлен на рисунке 16.
    • Рисунок 16 - Список форм подсистемы "Расписание экзаменационной сессии"
    • · "Edit Profile" - используется разработчиком для редактирования профильного документа БД. Форма содержит единственную кнопку, нажатие которой обеспечивает переход к редактированию профильного документа;
    • · "Profile" - определяет содержание профильного документа БД, используемого для обмена информацией между документами и агентами БД. Форма содержит поля, названия которых совпадают с названиями полей в других формах. Название этих полей определяется их "участием" в процессе обмена информацией между объектами БД.
    • · "Рабочее место";
    • · "Аудитория";
    • · "Начало-конец сессии";
    • · "Изменить расписание";
    • · "Время экзамена";
    • · "Календарь";
    • · "Календарь осенний";
    • · "Календарь весенний";
    • · "Кафедра";
    • · "Организация";
    • · "Оповещение";
    • · "Очистить расписание";
    • · "Подразделение";
    • · "Праздник";
    • · "Предустановка";
    • · "Учебный корпус";
    • · "Расписание";
    • · "Создать расписание";
    • · "Расписание сводное";
    • · "Расписание для кафедры".
    • Для отображения содержимого документов подсистемы, обеспечения доступа к ним и реализации функционала подсистемы, был создан набор представлений (видов).
    • Представление является средством навигации по БД Lotus Notes. Оно позволяет организовать выборку документов БД в список. В этом списке каждый документ представлен в виде отдельной строки. В свою очередь, строки представления состоят из колонок, каждая из которых содержит определённую информацию о документе (содержимое поля, результат вычисления и т.п.). Обычно в БД используется несколько представлений, отображающих документы БД. Список представлений подсистемы "Расписание экзаменационной сессии" представлен на рисунке 17.
    • Рисунок 17 - Список представлений подсистемы "Расписание экзаменационной сессии"
    • Информация, отображаемая в представлении, определяется как на этапе его проектирования, так и в процессе функционирования БД. Подмножество документов БД, отображаемое в представлении, определяется формулой (критерием) отбора документов в представление.
    • Агенты является элементами дизайна БД, предназначенными для автоматизации групповых действий над документами БД. Содержанием агента является программный модуль, реализующий требуемое действие над:
    • · всеми документами в БД;
    • · новыми и изменёнными документами;
    • · всеми документами в представлении;
    • · всеми выбранными документами в представлении
    • Агенты могут запускаться:
    • · из меню рабочей области Lotus Notes;
    • · из панели действий рабочего места Пользователя БД;
    • · из кнопок панелей действий представлений и документов;
    • · из других агентов;
    • · по расписанию;
    • · по наступлению предопределённого события (создание нового документа, наступление определённой даты и т.п.).
    • Агент, запущенный из одной БД может обрабатывать документы в другой БД, при условии, что такое право дано Пользователю, запускающему агент из "своей" БД. Действия, реализуемые агентами можно разделить на следующие группы:
    • · создание новых документов;
    • · выделение по заданному критерию документов в представлении;
    • · копирование/вставка документов;
    • · изменение содержания документов;
    • · удаление документов.
    • Для реализации функционала подсистемы "Расписание экзаменационной сессии" были разработаны следующие программные модули:
    • Подмодуль авторизации;
    • Модуль сохранения;
    • Программный модуль управления БД.
    • "Реплицирование" - реализует обмен данными (репликацию) БД, расположенной на сервере с её локальной репликой (её копией специального вида). При сохранении документа (кнопка "Сохранить") производится проверка расположения БД - анализируется значение служебного скрытого поля "Server", значение которого вычисляется с помощью формулы @Subset(@DbName; 1). Эта формула определяет имя сервера, на котором расположена БД. "Пустое" значение этого поля является признаком того, что текущая БД расположена локально на ПК Пользователя.
      • 4.1 Подмодуль авторизации
      • Перед тем как зайти в КИС РГУИТП пользователю необходимо авторизоваться. Каждый пользователь обладает определенным набором прав доступа к конкретной БД. После проверки пары логин-пароль системой пользователь может приступать к работе с БД. Алгоритм работы подмодуля авторизации изображен на рисунке 18.
      • Рисунок 18 - Алгоритм подмодуля авторизации
      • 4.2 Модуль сохранения
      • При открытии документа, мы вносим в него какие-либо данные, а затем сохраняем их. Для этого процесса создан модуль сохранения. Алгоритм модуля сохранения представлен на рисунке 19.
      • Рисунок 19 - Алгоритм работы модуля сохранения
      • 4.3 Программный модуль управления БД
      • Данный алгоритм отображает последовательность операций, которые может производить подсистема. Данный модуль содержит несколько операций:
      • · Действие;
      • · Создание;
      • · Просмотр;
      • · Выход из подсистемы.
      • Алгоритм работы программного модуля управления БД представлен на рисунке 20.
      • Рисунок 20 - Алгоритм программного модуля управления БД
      • 4.4 DFD диаграмма создания расписания экзаменов
      • Диаграмма потоков данных - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Описание потоков данных необходимо выполнить в DFD.
      • Ниже приведена диаграмма потоков данных составления расписания экзаменационной сессии (Рисунок 21). В качестве пользователя рассматривается методист Учебно - методического управления, которому необходимо составить расписание экзаменационной сессии.
      • Рисунок 21 - Диаграмма DFD

  • 5. Интерфейс подсистемы "Расписание экзаменационной сессии"

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

Рисунок 22 - Выбор пользователем необходимых действий

Рисунок 23 - Вывод обработанных данных на экран

  • 6. Оценка технической эффективности работы информационной подсистемы
    • В результате создания подсистемы "Расписание экзаменационной сессии" были выявлены параметры технической эффективности работы данной подсистемы. Оценка эффективности работы подсистемы проводилась по следующим критериям:
    • · Снижение трудозатрат. За счет внедрения подсистемы произойдет снижение трудозатрат на обработку информации на 564 человеко-часов (все расчеты приведены в экономической части).
    • · Расширение состава получаемой результативной информации. Возможность создания и просмотра расписания экзаменационной сессии по различным критериям.
    • · Повышение точности - сокращение ошибок. При базовом способе обработки информации методисты руководствуются практическим опытом и информацией, хранящейся "у них в головах", а не автоматизированной подсистемой, в которой хранятся все нужные данные. Методом экспертных оценок было определено, что при использовании подсистемы "Расписание экзаменационной сессии" повышение точности информации происходит на 20%-50% в зависимости от качества и систематичности ведения информационной базы подсистемы.
    • · Повышение производительности. Для определения трудозатрат на выполнение работы по составлению расписания экзаменационной сессии, был произведён хронометраж их выполнения в ручном режиме и с использованием подсистемы "Расписание экзаменационной сессии". Полученные данные представлены в таблице 3.
    • Таблица 3 - Результаты хронометража
    • Вид выполняемой операции

      Вручную (час.)

      По данным БД (час.)

      Повышение производительности

      Создание расписания экзаменационной сессии

      168

      48

      3,5

      Выборка экзаменов

      16

      6

      2,7

      Выборка аудиторий

      24

      10

      2,4

      Выборка по кафедрам

      24

      10

      2,4

      Выборка по группам

      24

      10

      2,4

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

      24

      10

      2,4

      Выборка по дате

      24

      10

      2,4

      • По результатам таблицы имеем среднее повышение производительности труда в 2,5 раза.
      • Заключение
      • В результате выполнения дипломного проекта была спроектирована подсистема "Расписание экзаменационной сессии" для АИС УМУ ВУЗа, рассчитаны ключевые показатели эффективности, проведен анализ существующих информационных систем по составлению расписания и обосновано решение о разработке нового продукта
      • Повышение эффективности работы по составлению расписания экзаменационной сессии за счет: снижения трудоемкости обработки информации на 564 человеко-часов. Сокращения годовых затрат на обработку информации на 136 174 рублей, уменьшения трудовых затрат в 3,3 раза, уменьшение стоимостных затрат в 2,7 раз.
      • Проанализированы потенциальные угрозы информационной безопасности подсистемы "Расписание экзаменационной сессии" и выбраны средства защиты от них.

      Подсистема "Расписание экзаменационной сессии" в составе КИС РГУИТП обеспечивает дистанционную работу пользователей подсистемы и осуществляет автоматизацию основных операций по сбору и обработке данных.

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

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

      • Список использованной литературы
      • 1. Положение Учебно-методического управления РГУИТП.
      • 2. ММИС Лаборатория/Приложение АВТОРасписание [Электронный ресурс] - Режим доступа: http://mmis.ru/Default.aspx?tabid=160
      • 3. Приложение "1С: ХроноГраф Расписание" [Электронный ресурс] - Режим доступа: http://www.1c.ru/news/info.jsp?id=4323
      • 4. Методология и технология проектирования АИС [Электронный ресурс] - Режим доступа: http://life-prog.ru/1_22687_tema--metodologiya-i-tehnologiya-proektirovaniya-ais-tipovoe-proektirovanie-ais.html
      • 5. Лекция 6: Методологии моделирования предметной области [Электронный ресурс] - Режим доступа: http://www.intuit.ru/studies/courses/2195/55/lecture/1628?page=5
      • 6. Больных А.А., Богданов В.Д., Старых В.А. Основы административного управления Lotus Domino и Lotus Notes версии 5. - М.: Европейский центр по качеству, 2003 г. - 160 с.
      • 7. Н.Н. Ионцев, В.К. Кулаков, В.А. Панов. Lotus Notes R.4: разработка приложений, язык LotusScript, встроенные классы. - С-Пб.: Издательская компания "Научная книга", 1996 г. - 574 с.
      • 8. UML: специальный справочник / Рамбо Дж., Якобсон А., Буч Г. // СПб.: Питер, 2002. - 656 с.
      • 9. Трофимов С.А. Case-технологии: практическая работа в Rational Rose. Бином-средств, 2002.
      • 10. Коваленко В. В.. Проектирование ИС. РГРТУ, Рязань, 2006.
      • 11. Е.В. Поляков. Domino Designer R6.5 - интегрированная среда разработки приложений в Lotus Domino. - М.: ООО Фирма "Светотон" ЛТД.
      • Размещено на Allbest.ru

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.