Автоматизированный учет расчетов за проживание в общежитии студенческого городка

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

Автоматизированный учет расчетов за проживание в общежитии студенческого городка

Бережная И.В., Путивцева Н.П.



СОДЕРЖАНИЕ

Введение

1. Теоретическая часть

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

1.2 Изучения методологий

1.3 Общие сведения о проектировании базы данных

1.3.1 Логическая модель

1.3.2 Физическая модель

1.4 Теоретические сведенья о пользовотельском интерфейсе

2. Проектирование информационной системы

2.1 Предпроектное обследование предметной области

2.1.1 Построение моделей IDEF0

2.1.2 Построение моделей IDEF3

2.1.3 Построение моделей DFD

2.1.4 Построение моделей UML

2.2 Разработка базы данных

2.2.1 Построение логической модели в нотации IDEF1X

2.2.2 Физическое проектирование базы данных

2.3 Проектирование пользовательского интерфейса

Заключение

Список использованных истачников

Приложение



Введение

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

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

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

Задачи, которые необходимо реализовать в курсовой работе:

провести анализ предметной области "Учет расчетов за проживание в общежитии";

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

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

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

смоделировать модели при помощи популярных нотаций, таких как

IDEF0, IDEF3, DFD, UML;

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

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

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

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

Данная курсовая работа состоит из 2 разделов, 32 страниц, 2 таблиц, 23 рисунков.



1. Теоретическая часть

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

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

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

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

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

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

горячее водоснабжение;

холодное водоснабжение;

водоотведение;

электроснабжение;

отопление.

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

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

1.2 Изучение методологий

Сущность методологии IDEF0

Методология функционального моделирования IDEF0 - это методология описания системы в целом как множества взаимозависимых действий или функций. Наиболее часто IDEF0 применяется как технология исследования и проектирования систем на логическом уровне [2]. По этой причине она, как правило, используется на ранних этапах разработки проекта. Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных. [6]

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

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

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

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

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

Стрелки механизма исполнения. Механизм исполнения является ресурсом, который непосредственно исполняет моделируемое действие. В качестве механизмов исполнения обычно выступают персонал или техника. Комбинированные стрелки.

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

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

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

Сущность методологии IDEF3

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

IDEF3 не имеет жестких синтаксических или семантических ограничений.

Основой модели IDEF3 служит так называемый сценарий бизнеспроцесса, который выделяет последовательность действий или процессов анализируемой системы. [8]

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

Таблица 1 - Типы соединений в модели IDEF3

Графическое обозначение	Название	Вид	Правила инициации
	Соединение «И»	Разворачивающее	Каждое конечное действие обязательно инициируется
		Сворачивающее	Каждое исходное действие обязательно должно завершиться
	Соединение «ИЛИ»	Разворачивающее	Одно (или более) конечное действие инициируется
		Сворачивающее	Одно (или более) исходное действие должно завершиться
	Соединение «Исключающее ИЛИ»	Разворачивающее	Одно и только одно конечное действие инициируется
		Сворачивающее	Одно и только одно исходное действие должно завершиться

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

Таблица 2 - Синхронные соединения модели IDEF3

Графическое обозначение	Название	Вид	Правила инициации
	Соединение «И»	Разворачивающее	Все действия начнутся одновременно
		Сворачивающее	Все действия закончатся одновременно
	Соединение «ИЛИ»	Разворачивающее	Может быть, несколько действий начнутся одновременно
		Сворачивающее	Может быть, несколько действий закончатся одновременно

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

Структурный анализ потоков данных. Сущность структурного анализа потоков данных

Методология DFD или диаграмм потоков данных это методология описания системы, позволяющая отражать такие характеристики, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности). [6]

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

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

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

Синтаксис и семантика диаграмм потоков данных. Функциональные блоки DFD изображаются в виде прямоугольников с округленными углами. Функциональные блоки DFD почти идентичны функциональным блокам IDEF0 и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения, как IDEF0.

Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель).

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

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

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

Диаграммы UML

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

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

В UML выделяют следующие типы диаграмм:

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

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

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

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

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

1.3 Общие сведения о проектировании баз данных

База данных - набор сведений, хранящихся некоторым упорядоченным способом. Можно сравнить базу данных со шкафом, в котором хранятся документы. Иными словами, база данных - это хранилище данных. Сами по себе базы данных не представляли бы интереса, если бы не было систем управления базами данных (СУБД). [1]

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

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

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

Связь - функциональная зависимость между объектами. В реляционных базах данных между таблицами устанавливаются связи по ключам, один из которых в главной (parent, родительской) таблице - первичный, второй - внешний ключ - во внешней (child, дочерней) таблице, как правило, первичным не является и образует связь "один ко многим" (1:N). В случае первичного внешнего ключа связь между таблицами имеет тип "один к одному" (1:1). Информация о связях сохраняется в базе данных.

1.3.1 Логическая модель

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

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

1.3.2 Физическая модель

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

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

1.4 Теоретические сведенья о пользовательском интерфейсе

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

Интерфейс пользователя - набор методов взаимодействия компьютерной программы и пользователя этой программы.

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

Физический интерфейс - способ взаимодействия физических устройств. Чаще всего речь идёт о компьютерных портах.

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

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

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



2. Проектирование информационной системы

2.1 Предпроектное обследование предметной области

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

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

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

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

Для данной работы требуется определить цели и задачи данной темы. Выполнить структурный анализ задачи, и оформите результат данного анализа в виде диаграмм IDEF0. Так же выполнить детализацию отдельных процессов на диаграммах IDEF0, с помощью диаграмм IDEF3. После нужно составить отдельную модель DFD, и построить UML модель. Далее требуется разработать БД, обеспечивающую автоматизацию процессов ведения и распространения информации о студентах, проживающих в общежитиях. Студенты, проживающие в общежитии, при поступлении заполняют необходимые документы. Потребителем информации из БД являются комендант, обеспечивающий проживание приезжих студентов. Для внесения входной информации создана база данных.

2.1.1 Построение моделей IDEF0

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

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

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

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

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

В ходе работы была смоделирована диаграмма IDEF0 "Автоматизация учета расчетов за проживание в студенческом общежитии". На изображениях видно как по этапно проходит процес декомпозиций. Для дальнейшей детализации функциональных блоков будем использовать диаграммы IDEF3, которые будут разработаны в пункте (2.1.2.).

2.1.2 Построение моделей IDEF3

Декомпозиция отдельных процессов при помощи нотации IDEF3. Таких процессов как «Расчёт платы за помещение» и «Расчёт платы за комунальные услуги» которые представленны на рисунках 2.6 и 2.7.

На данном рисунке 2.6 построена декомпозиции блока "Расчёт платы за помещение" при помощи нотации IDEF3. Показано детально как происходит расчет платы за помещение.

В ходе работы была смоделирована диаграмма IDEF3 "Автоматизация учета расчетов за проживание в студенческом общежитии". Выполнена детализация отдельных процессов на диаграммах IDEF0, полученных при выполнении предыдущего пункта (2.1.1.) с помощью диаграмм IDEF3.

2.1.3 Построение моделей DFD

На рисунках 2.8 и 2.9 были составлены отдельные модели при помощи методологии DFD.

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

Была осуществлена декомпозиция контекстной диаграммы

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

2.1.4 Построение моделей UML

В данном разделе представлено моделирование при помощи UML моделей.

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

На данной картинке показано как взаимодействуют процессы с объектами.

Рисунок 2.11 - Результат создания блок-схемы процессов

На рисунке 2.11 показанна блок-схема процессов, то есть как система по запросом быдаёт результат.

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

Рисунок 2.13 - Результат создания диаграмы классов

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

2.2 Разработка базы данных

2.2.1 Построение логической модели в нотации IDEF1X

Рисунок 2.14 - Результат построения логической модели в нотации IDEF1X

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

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

Было выполнено информационное моделирование бизнес-процессов. Моделирование осуществлялось на логическом уровне. Создано 8 таблиц таких как (арендаторы, статус арендатора, комнаты, общежитие, сотрудники, тип комнат общежития, журнал, квитанция) и построены связи между таблицами. Так же определены первичные и вторичные ключи, и установлены типы данных.

У сущности "Арендаторы" есть первичный ключ (Номер арендатора), и атрибуты (ФИО, Номер статуса, Дата заселения, Дата выселения, Номер комнаты, Номер общежития, Номер типа). У сущности "Статус арендатора" есть такие атрибуты как (Номер статуса, Статус). У сущности "Комнаты" есть первичный ключ (Номер комнаты), и атрибуты (Номер общежития, Номер типа, Количество мест). У сущности "Общежитие" есть первичный ключ (Номер общежития), и атрибуты (Адрес, Количество комнат, Количество этажей, Номер сотрудника). У сущности "Сотрудники" есть первичный ключ (Номер сотрудника), и атрибуты (ФИО, Полномочия, Логин, Пароль). У сущности "Тип комнат общежития" есть первичный ключ (Номер типа), и атрибуты (Название типа). У сущности "Журнал" есть первичный ключ (Номер в журнале), и атрибуты (Дата выезда, Дата приезда, Причина). У сущности

"Квитанция" есть первичный ключ (Номер квитанции) и атрибуты (Номер арендатора, Сумма найма, Коммунальные услуги, Дополнительные услуги, Общая стоимость).

2.2.2 Физическое проектирование базы данных

Рисунок 2.15 - Результат построения физической модели в нотации

IDEF1X

Физический уровень модели ERwin составляют целевая СУБД, имена объектов, типы данных и индексы.

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



2.3 Проектирование пользовательского интерфейса

В данном разделе была проведена работа по проектированию пользовательского интерфейса. Проектирование информационной системы осуществлялось в программной среде Microsoft Visual Studio.

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

Рисунок 2.16 - Изображение окна авторизации

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



Рисунок 2.17 - Главное меню приложения

На странице профиль сотрудника располагается личная информация о сотруднике, такая как “Логин”, “Фамилия”, “Должность” и так далее. На данной странице так же имеется возможность изменить пароль и изменить или добавить фотографию. Страница изображена на рисунке 2.18.

Рисунок 2.18 - Профиль сотрудника

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

Рисунок 2.19 - Страница “Поиск арендатора”

Профиль арендатора включает в себя 2.20 три основных зоны: “Личная информация”, “Данные общежития”, Информация о задолженностях”. Информация о задолженностях выглядит в виде таблице. Так же на данной странице существует возможность импорта в MS Word, а также MS Excele.

Рисунок 2.20 - Профиль арендатора

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



Рисунок 2.21 - Добавить арендатора

На рисунке 2.22 и 2.23 страницы просмотров данных. При просмотре общежития можно выбрать двойным кликом конкретное общежитие, а далее и конкретную комнату или студента. При двойном клики на студента будет открыта страница профиля студента. Во время просмотра журнала можно осуществить поиск по журналу и узнать дату выезда или въезда студента.

Рисунок 2.22 - Просмотр общежитий



Рисунок 2.23 - Просмотр журнала



Заключение

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

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

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

Главные вопросы, которые были рассмотрены в данной курсовой работе:

3. Проанализирована предметная область, изучены основные понятии.

4. Были изучены основные методологии.

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

6. Изучена информация о создании логической и физической модели баз данных.

7. Были построены модели IDEF0, IDEF3, DFD, UML.

8. Были определенны основные сущности для проектирования и разработки базы данных.

9. Построены логическая и физическая модель для базы данных при помощи методологии UML.

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



Список использованных источников

1. Кузин А.В., Левонисова С.В. Базы данных [Текст], Издательство Академия, 2012г.

2. Зыков С. Основы проектирования информационных систем [Текст], Издательство дом Высшей школы экономики. 2012г.

3. Купер А. Интерфейс. Основы проектирования и взаимодействия (четвертое издание) [Текст], 2017г.

4. Фаулер М. Шаблоны корпоративных приложений [Текс],

Издательство Вильямс 2016г. - 544с.

5. Коваленко В.В. Проектирование информационных систем [Текс], Издательство Форум 2014г.

6. Учебно-практическое пособие по "Проектировании информационных систем".

7. Исаева Г. Проектирование информационных систем [Текс].

Издательство Омега-Л 2012г. - 432с.

8. Зиборов В.В.MS Visual C++ 2010 в среде .NET Год издания:2012 Страниц:320

9. Алексеев А.А.Основы параллельного программирования с использованием Visual Studio 2010. 2-е изд. 2016г.332с.

10. Бодров, О.А. Предметно-ориентированные экономические

информационные системы: Учебник для вузов / О.А. Бодров. - М.: Гор. линия-

Телеком, 2013г. - 244 c

11. Бодров, О.А Предметно-ориентированные экономические информационные системы / О.А Бодров. - М.: ГЛТ, 2013г. - 244 c.

12. Уткин, В.Б. Информационные системы в экономике: Учебник для студентов высших учебных заведений / В.Б. Уткин, К.В. Балдин. - М.: ИЦ Академия, 2012г. - 288 c.

13. Информационные системы и технологии: Научное издание. / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2016г. - 303 c.

14. Учебное пособие по "Теории систем и системный анализ" и Глоссарий.

15. Мезенцев, К.Н. Автоматизированные информационные системы: Учебник для студентов учреждений среднего профессионального образования / К.Н. Мезенцев. - М.: ИЦ Академия, 2013. - 176 c.



Приложения

ТЗ на разработку автоматизированного учета расчетов в студенческом городке за проживание в общежитии.

1.Введение

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

2.Основание для разработки

Основанием для разработки является задание в рамках курса «Проектирование информационных систем».

3.Назначение разработки АСУ предназначена для решения следующих задач:

16. Хранение информации о клиентах проживающих в различных общежитиях, типы комнат с указанием периода поселения студента.

17. Фиксация всех происходящих в системе событий.

18. Формирование квитанций за проживание в общежитии.

19. Контроль за порядком жилого помещения.

20. Своевременная плата за проживание.

4.Требования к программному изделию

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

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

21. ФИО сотрудника;

22. имя в системе;

23. пароль;

24. полномочия.

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

25. ФИО арендатора общежития;

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

27. статус проживающего;

28. общежитие;

29. сроки заселения и выселения;

30. тип комнаты;

31. институт (факультет);

32. номер этажа общежития;

33. стоимость за проживание; · заключение договора;

34. оформление регистрации.

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

35. номер общежития; · адрес общежития;

36. количество этажей;

37. количество мест;

38. количество комнат;

39. количество проживающих;

40. тип комнат;

41. количество мест в комнатах.

5.Назначение платежа за проживание в общежитии:

42. плата за найма;

43. коммунальные услуги;

44. дополнительный услуги;

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

7.Формирование, хранение, печать, экспорт в другие форматы журнала событий выезда-въезда:

45. код события;

46. дата события;

47. информация о клиенте (причина выезда);

48. перерасчет квитанции за общежитие.

Входной информацией системы является:

1.Бухгалтерская информация:

49. информация о сроке действия договора клиента о найме жилого помещения;

50. информация об оплате клиентом квитанций за проживание, оговоренная в договоре.

2.Регистрационная информация:

51. информация об общежитиях и комнатах;

52. информация о клиентах общежития .

Выходной информацией системы является:

1.Управляющие воздействия на использование комнатой и своевременная выплата за комнату.

2.Отчеты. Минимальный перечень формируемых в системе отчетов следующий:

53. список свободных комнат(мест);

54. список занятых комнат(мест);

55. список клиентов; · задолженности клиентов.

4.2. Требования к надежности Система должна:

56. проводить контроль платы за проживание;

57. блокировать некорректные действия пользователя при работе с системой;

58. обеспечивать целостность данных.

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

Использовать систему будут пользователи средней и низкой квалификации.

Интерфейс системы должен быть максимально приближен к интерфейсам подобных систем.

Ввод информации должен осуществляться в наиболее унифицированных формах.

60. Требования к составу и параметрам технических средств

Настоящая система должна работать на компьютерах IBM PC. Оперативная память на каждом компьютере, не менее 128 Мб. Свободное место на жестком диске не менее 10Гб.

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

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

62. Требования к маркировке и упаковке

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

63. Требования к транспортированию и хранению

Требования к транспортированию и хранению программного изделия совпадают с аналогичными требованиями, предъявляемыми к компакт-дискам.

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

Программная документация должна содержать следующие документы (см. ГОСТ

19.101-77):

1.Программные документы:

64. Спецификация (ГОСТ 19.202-78);

65. Текст программы (ГОСТ 19.401-78);

66. Описание программы (ГОСТ 19.402-78); · Пояснительная записка (ГОСТ 19.404-79); 2.Эксплуатационные документы:

67. Ведомость эксплуатационных документов (ГОСТ 19.507-79);

68. Формуляр (ГОСТ 19.501-78);

69. Описание применения (ГОСТ 19.502-78);

70. Руководство системного программиста (ГОСТ 19.503-79);

71. Руководство программиста (ГОСТ 19.504-79);

72. Руководство оператора (ГОСТ 19.505-79);

Требования к перечисленным документам не отличаются от требований, определенных в ЕСПД.

Размещено на Allbest.ru

...