теория информационных процессов и систем. Отчет. Курсовая работа 1 Вариант 7 по методам и средствам проектирования информационных систем и технологий

Название	Курсовая работа 1 Вариант 7 по методам и средствам проектирования информационных систем и технологий
Анкор	теория информационных процессов и систем
Дата	06.09.2022
Размер	0.71 Mb.
Формат файла
Имя файла	Отчет.docx
Тип	Курсовая #664693

Поволжский государственный университет телекоммуникаций и

информатики

Заочный факультет

РЕГИСТРАЦИОННЫЙ № ______

Курсовая работа №_1_____ Вариант __7____

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

Студент Богородцев Сергей Александрович

Факультет ЗО курс 3 шифр _193097____ гр. ИСТ-3К

Работа выслана «» 2022г.

Оценка _______________ Дата _______________20___г.

Подпись преподавателя ___________________

Контрольная работа вместе с рецензией предъявляется

экзаменатору при сдаче экзамена

Рецензия

Аннотация
Курсовой проект на тему: проектирование системы для военного училища. Выполнил: Богородцев Сергей Александрович, рисунков 10, количество источников 14, 31 страница.

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

Ключевые слова: проектирование, UML, StarUML, Ramus, IDEF0.

Содержание

Введение

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

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

Это позволяет увеличить скорость и качество работы специалиста этой области.

Тема данного курсового проекта: проектирование системы для «Военное училище».

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

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

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

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

Цель курсового проекта: проектирование системы для военного училища, получение практических навыков в проектировании корпоративных информационных систем.

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

представить развёрнутое содержательное описание компании;
выполнить анализ работы компании и описать её процессы;
построить модель процессов (IDEF0);
построить модель данных (ER-диаграмма);
построить модель ИС компании средствами UML.

1. Модель процессов в Ramus

IDEF относится к семейству языков моделирования, которое охватывает широкий спектр применений, начиная от функционального моделирования и заканчивая данными, моделированием, объектно-ориентированным анализом и сбором информации. Методы IDEF описаны от IDEF0 до IDEF14.

IDEF (Integrated Definition) – это графический метод моделирования процессов, используемый для применения процессов и инженерных приложений.

IDEF был задуман ВВС США и разработан в середине 1970-х годов. Он был разработан как основной инструмент для записи бизнес-процессов и их оценки. Теперь этот метод используется в качестве жесткой основы для изучения организации, фиксации моделей процессов «как есть» и моделирования операций бизнес-сообщества.

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

IDEF0 был разработан на основе хорошо известного графического языка структурного анализа и проектирования (SADT). Эффективные модели IDEF помогают упростить разработку устройств и способствуют эффективному сотрудничеству между аналитиками и клиентами.

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

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

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

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

Рисунок 1 – IDEF0 Контекстная диаграмма модели функционирования
К входам кафедры относятся следующие потоки:

дисциплины;
курсанты;
преподаватели.

На выходе:

отчет об успеваемости;
расписание;
отчет по кафедре.

Механизмы: сотрудники.

Правила:

законы РФ;
устав кафедры.

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

Рисунок 2 – IDEF 0 Декомпозиция контекстной диаграммы
Контекстная диаграмма была разбита на 4 основных блока:

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

Для более подробного изучения формирования расписания была произведена декомпозиция по функциональному признаку. Полученная декомпозиция показана на рисунке 3.

Рисунок 3 – Декомпозиция блока «Формирование расписания» DFD
К входам кафедры относятся следующие потоки: дисциплины.

На выходе:

данные по датам;
расписание.

Механизмы: сотрудники.

Правила: устав кафедры.

Блок «Формирование расписания» был разбит на 5 основных блоков:

учебный план;
работа с группами;
работа со студентами;
формирование списка отличников;
формирование всего списка оценок.

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

Рисунок 4 – Декомпозиция блока «Учет успеваемости» IDEF0

Для более подробного изучения формирования учебного плана была произведена декомпозиция по функциональному признаку. Полученная декомпозиция показана на рисунке 5.

Рисунок 5 - Декомпозиция блока «Формирование учебного плана» IDEF0
К входам относятся следующие потоки: данные по датам.

На выходе: отчет по кафедре.

Механизмы: сотрудники.

Правила:

законы РФ;
устав кафедры.

Блок «Формирование учебного плана» был разбит на 6 основных блоков:

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

2. Модель данных

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

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

Концептуальная модель данных, в которой отсутствуют конкретные детали, но которая дает представление о масштабах проекта и о том, как наборы данных соотносятся друг с другом.
Логическая модель данных, более подробная, чем концептуальная модель данных, иллюстрирующая определенные атрибуты и отношения между точками данных. Хотя концептуальную модель данных не нужно разрабатывать перед логической моделью данных, физическая модель данных основана на логической модели данных.
Физическая модель данных, обеспечивающая схему физического воплощения (например, реляционной базы данных) логической модели данных. На основе логической модели данных можно разработать одну или несколько физических моделей данных.

Три основных связи:

Отношения один к одному (1:1). Например, если каждый клиент в базе данных связан с одним почтовым адресом.
Связь «один ко многим» (1:M). Например, один клиент может разместить заказ на несколько продуктов. Клиент связан с несколькими объектами, но все эти объекты имеют одно обратное соединение с одним и тем же клиентом.
Связь «многие ко многим» (M:N). Например, в компании, где все операторы центра обработки вызовов работают с несколькими клиентами, каждый оператор связан с несколькими клиентами, а несколько клиентов также могут быть связаны с несколькими операторами.

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

Физическая диаграмма для военного училища показана на рис.6.

Рисунок 6 – Физическая схема военного училища
Выделены девять таблиц:

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

3. Модель в StarUML

3.1 Диаграмма вариантов использования

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

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

Только статического поведения недостаточно для моделирования системы, скорее динамическое поведение важнее статического поведения.

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

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

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

Диаграмма прецедентов «Военное училище» представлена на рисунке 7 – 9.

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

Рисунок 8 – Диаграмма вариантов использования для курсанта

Рисунок 9 – Диаграмма вариантов использования для администратора

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

Вариант использования 1: Вход в систему

Рамки: «Система для преподавателя»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: -

Основной успешный поток событий (сценарий):

1. Пользователь: вводит логин и пароль

2. Пользователь: нажимает на кнопку входа

3. Система: проверяет пользователя в базе данных

4. Система: правильный логин и пароль

5. Открытие главной страницы

5. Сценарий завершен

Альтернативный поток событий 1а:

1. Пользователь: вводит логин и пароль

2. Пользователь: нажимает на кнопку входа

3. Система: проверяет пользователя в БД

4. Система: выдача ошибки «неправильный логин или пароль»

5. Сценарий завершен

Альтернативный поток 1б:

1. Пользователь: вводит логин

2. Пользователь: нажимает на кнопку входа

3. Система: выдача ошибки «не все поля введены»

4. Сценарий завершен.

Постусловия (результаты)

Открытие главной страницы

Частота использования: при каждом запуске приложения

Вариант использования 2: Оценивание

Рамки: «Система для преподавателя»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Пользователь: выбирает расписание

2. Система: отправляет запрос на выборку данных о преподавателе и дисциплины и открывает страницу выбора курсанта.

3. Пользователь: выбор курсанта и тип оценки

4. Система: добавляет новую оценку по расписанию

5. Система: возвращение к шагу 2

6. Сценарий завершен

Альтернативный поток событий 1а:

1. Пользователь: выбирает расписание

2. Система: отправляет запрос на выборку данных о преподавателе и дисциплины и открывает страницу выбора курсанта.

3. Пользователь: выбор курсанта и тип оценки

4. Система: ошибка добавления данных не корректный тип данных «Оценка»

5. Система: возвращение к шагу 2

Постусловия: добавление новой оценки

Частота использования: при каждом добавлении новой оценки

Вариант использования 3: Просмотр посещаемости

Рамки: «Система для преподавателя»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Пользователь: выбирает группу

2. Система: отправляет запрос на выборку всех групп из базы данных.

3. Пользователь: выбор группы

4. Система: отправляет запрос на выборку посещаемости по группе

5. Система: возвращение к шагу 1

6. Сценарий завершен

Постусловия: вывод посещаемости

Частота использования: при каждом выборе просмотра посещаемости

Вариант использования 4: Просмотр расписания

Рамки: «Система для преподавателя»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Система: выбирает расписание по авторизированном пользователе.

2. Пользователь: выбор группы

3. Система: фильтрует расписание по группе

4. Сценарий завершен

Постусловия: вывод расписания

Частота использования: при выборе расписания

Вариант использования 5: Просмотр успеваемости

Рамки: «Система для преподавателя»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Система: выбирает список групп, который ведет преподаватель.

2. Пользователь: выбор группы

3. Система: фильтрует успеваемость по группе

4. Сценарий завершен

Постусловия: вывод успеваемости

Частота использования: при выборе успеваемости

Вариант использования 6: Просмотр успеваемости

Рамки: «Система для курсанта»

Уровень: Задача, определенная пользователем

Основной актёр: курсант

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Система: выбирает по авторизированному курсанту.

3. Система: фильтрует успеваемость по студенту

4. Сценарий завершен

Постусловия: вывод успеваемости

Частота использования: при выборе успеваемости

Вариант использования 7: Просмотр расписания

Рамки: «Система для курсанта»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Система: выбирает расписание по авторизированному курсанту.

2. Система: фильтрует расписание по курсанту

3. Сценарий завершен

Постусловия: вывод расписания

Частота использования: при выборе расписания

Вариант использования 7: Просмотр расписания

Рамки: «Система для курсанта»

Уровень: Задача, определенная пользователем

Основной актёр: преподаватель

Предусловие: авторизированно в системе

Основной успешный поток событий (сценарий):

1. Система: выбирает расписание по авторизированному курсанту.

2. Система: фильтрует расписание по курсанту

3. Сценарий завершен

Постусловия: вывод расписания

Частота использования: при выборе расписания

Вариант использования 8: Вход в систему

Рамки: «Система для курсанта»

Уровень: Задача, определенная пользователем

Основной актёр: курсант

Предусловие: -

Основной успешный поток событий (сценарий):

1. Пользователь: вводит логин и пароль

2. Пользователь: нажимает на кнопку входа

3. Система: проверяет пользователя в базе данных

4. Система: правильный логин и пароль

5. Открытие главной страницы

5. Сценарий завершен

Альтернативный поток событий 1а:

1. Пользователь: вводит логин и пароль

2. Пользователь: нажимает на кнопку входа

3. Система: проверяет пользователя в БД

4. Система: выдача ошибки «неправильный логин или пароль»

5. Сценарий завершен

Альтернативный поток 1б:

1. Пользователь: вводит логин

2. Пользователь: нажимает на кнопку входа

3. Система: выдача ошибки «не все поля введены»

4. Сценарий завершен.

Постусловия (результаты)

Открытие главной страницы

Частота использования: при каждом запуске приложения

3.2 Диаграмма классов

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

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

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

Рисунок 10 – Диаграмма классов
Было выделено 9 классов:

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

Выводы

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

Были решены следующие задачи:

описаны и созданы диаграммы IDEF0 и DFD;
выполнен анализ работы военного училища, а также его процессы;
построена модель данных (ER-диаграмма);
построена диаграмма классов;
построена диаграмма вариантов использования.

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

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

Библиографический список

1. Бабич, А. В. UML. Первое знакомство. Пособие для подготовки к сдаче теста UMO-100 (OMG Certified UML Professional Fundamental) (+ CD-ROM) / А.В. Бабич. - М.: Бином. Лаборатория знаний, 2008. - 176 c.

2. Боггс, М. UML и Rational Rose / М. Боггс. - Москва: РГГУ, 2010. - 385 c.

3. Бородакий, Ю. В. Эволюция информационных систем / Ю.В. Бородакий, Ю.Г. Лободинский. - Москва: СИНТЕГ, 2011. - 368 c.

4. Буч, Гради Введение в UML от создателей языка / Гради Буч , Джеймс Рамбо , Ивар Якобсон. - М.: ДМК Пресс, 2015. - 496 c.

5. Буч, Грейди Язык UML. Руководство пользователя / Грейди Буч , Джеймс Рамбо , Айвар Джекобсон. - М.: ДМК, 2015. - 432 c.

6. Гома, Хассан UML. Проектирование систем реального времени, параллельных и распределенных приложений / Хассан Гома. - М.: ДМК Пресс, 2016. - 700 c.

7. Грекул, В. И. Управление внедрением информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - Москва: РГГУ, 2014. - 224 c.

8. Гультяев, А. К. Проектирование и дизайн пользовательского интерфейса / А.К. Гультяев, В.А. Машин. - М.: Корона-Принт, 2010. - 350 c.

9. Данелян, Т. Я. Экономические информационные системы (ЭИС) предприятий и организаций / Т.Я. Данелян. - М.: Юнити-Дана, 2015. - 284 c.

10. Зенков, В. В. Методы и алгоритмы компьютерной обработки геологической и маркшейдерской информации. Практика обработки заводских данных / В.В. Зенков, О.А. Поляков, В.Е. Юрченко. - М.: Ленанд, 2013. - 268 c.

11. Йордон, Эдвард Объектно-ориентированный анализ и проектирование систем / Эдвард Йордон , Карл Аргила. - М.: ЛОРИ, 2014. - 264 c.

12. Карпов, Ю. Г. Model Checking. Верификация параллельных и распределенных программных систем (+ CD-ROM) / Ю.Г. Карпов. - М.: БХВ-Петербург, 2010. - 552 c.

13. Киммел, Пол UML. Основы визуального анализа и проектирования / Пол Киммел. - М.: НТ Пресс, 2008. - 272 c.

14. Коберн, Алистер Современные методы описания функциональных требований к системам / Алистер Коберн. - Москва: Машиностроение, 2012. - 264 c.