Информационная система «Видеопрокат»
ОАНО «Волжский университет им. В.Н. Татищева»
Факультет «Информатика и телекоммуникации»
Кафедра «Промышленная информатика»
КУРСОВАЯ РАБОТА
по дисциплине «Проектирование информационных систем»
на тему: «Информационная система «Видеопрокат»
Выполнил: студент группы ИТ-405
Маркова Т.И. __________________
Дата сдачи ____________________
Дата проверки _________________
Тольятти, 2007
Содержание
ВВЕДЕНИЕ
Целью курсовой работы является разработка программного продукта, позволяющего автоматизировать документооборот в магазине. Для разработки будет использоваться язык UML и программный пакет Rational Rose.
UML включает набор графических элементов, используемых на диаграммах, и правила для объединения этих элементов. Диаграммы используются для отображения различных представлений системы. Этот набор представлений называется моделью.
UML-модель описывает, что должна делать система, но ничего не сообщает о том, как она будет реализована.
1 Описание информационной системы для организации товарооборота и обработки платежей в магазине видеопроката
В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, т. е. представление разрабатываемого программного обеспечения в виде совокупности объектов, в процессе взаимодействия которых через передачу сообщений и происходит выполнение требуемых функций.
Данная курсовая работа включает анализ объекта управления и его основные технико-экономические показатели.
Изначальное поведение разрабатываемой системы описывается с помощью функциональной модели, которая отображает системные прецеденты, системное окружение и связи между прецедентами и актёрами. Задача модели – представлять единое средство, дающие возможность заказчику и разработчику совместно обсуждать функциональность и поведение системы.
Изучив работу, выполняемую персоналом фирмы (актёров), и подобрав именно тех специалистов (нужных специальностей), начинает выполняться работа для взаимодействия системы.
1.1 Характеристика существующей организации обработки информации в магазине видеопроката
В курсовой работе представлена модель работы магазина видеопроката, который использует для отслеживания товарного оборота персональные компьютеры.
На диаграмме прецедентов для системы чётко прослеживается работа каждого участника системы, кто и за что отвечает.
1.2 Информационные данные, обеспечивающие вариантность решения задачи
Клиент приходит в магазин «Видеопрокат», чтобы взять на прокат какое-нибудь видео, консультант рассказывает ему о всех поступивших новинках и помогает выбрать ему фильм. Если клиент пришел за конкретным видео, то тогда клиент подойдя к оператору узнает у него, есть ли это видео в наличии или нет, тем самым оператор связавшись с сервером, в котором хранится база данных, узнать быстро есть ли интересующий клиента фильм на складе.
Когда выбор сделан, клиент предоставляет индивидуальную карточку «клиента», на которой указан его индивидуальный номер, оператору и оплачивает товар. Если у клиента нету индивидуальной карточки, то тогда клиента регистрирует оператор и выдает ему эту карточку, для этого нужен только паспорт.
Внеся номер карточки клиента в базу данных, оператор узнает нет ли задолжностей у клиента, количество взятых видео продукции данным клиентом, внести данные о видео которое берет клиент. Если количество взятых видео клиентом превышает 40 шт., то клиенту разрешается брать видео на прокат только на 2 суток.
1.3 Словарь специальных терминов, характеризующих объект
Оператор – сотрудник магазина «Видеопроката», который выдает клиентам видео продукцию и карточки, принимает деньги, а также оформляет учет поступившей продукции.
Клиент – человек, который берет видео продукцию на прокат в магазине
Консультант – сотрудник магазина, основной задачей которого является помочь клиентам в выборе видео продукции, также он должен владеть информацией о видео.
Поставщик – человек, следящий за рынком видео и поставляющий видео продукцию в магазин.
2 Разработка автоматизированной
системы для организации
товарооборота и обработки платежей
в магазине видеопроката
Разрабатываемая система должна иметь широкую организационную структуру. Далее дано обоснование на разработку системы, а так же приведена ее архитектура, на основании которой будут строиться отдельные функциональные части.
2.1 Техническое задание на разработку ПП
Данный программный продукт разрабатывается на основании технического задания.
ВВЕДЕНИЕ
Настоящее техническое задание распространяется на разработку программы документооборота для использования сотрудниками видеопроката.
При регистрации новых клиентов, организации товарооборота видео проката нужно разработать такую систему, чтобы сделать этот процесс систематичным, оптимальным, производительным.
Существующее программное обеспечение не может решать подобные задачи и не является универсальным. Для этого необходимо разработать такое программное обеспечение, чтобы решить данную задачу.
Во время работы необходимо получение оперативной информации о видео имеющегося в магазине и у клиентов, однако выполнение такого контроля вручную требует значительного времени. Автоматизированная система работы сотрудников позволит улучшить качество и скорость работы над документами. Хранение документации в электроном виде позволит увеличить скорость обработки и поиска нужной продукции.
Предполагается, что использовать данную систему будут сотрудники видеопроката, разрабатываемая программа позволит сотрудникам упростить работу с документами.
1 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ
Основанием для разработки программы является задание на курсовую проект по дисциплине «Проектирование информационных систем», утвержденное кафедрой «Промышленная информатика», 5.02.2007. Тема «Разработка автоматизированной системы для организации товарооборота и обработки платежей в магазине «Видеопрокат»
2 НАЗНАЧЕНИЕ
Система предназначена для хранения и обработки сведений о видеоносителях, клиентах и платежах.
3 ТРЕБОВАНИЯ К ПРОРАММНОМУ ИЗДЕЛИЮ
- Требования к функциональным характеристикам
Программа должна обеспечивать возможность выполнения следующих функций:
- ввод и коррекция текущей информации о взятие и сдачи видео конкретными клиентами;
- ввод и коррекция информации о клиентах в присвоение индивидуального номера;
- хранение информации о видео имеющихся в наличии и данных в прокат;
- ввод и коррекция информации о поступившей продукции;
- подсчет количества взятых кассет каждым клиентом.
Исходные данные:
- данные клиентов и номера их карточек;
- текущие сведения о количестве взятых кассет каждым клиентом;
- список фильмов на видео;
- регистрация штрафные санкции.
- Требования к надежности
Разрабатываемая система должна отвечать следующим требованиям надежности:
- контроль входной и выходной информации;
- отсутствие ошибок;
- устойчивость к ошибкам;
- резервное копирование в конце рабочего дня;
- разграничение прав доступа;
- время восстановления после отказа t=1 минута.
- Условия эксплуатации
Должны быть соблюдены допускаемые воздействия климатических условий. Микроклимат помещений в соответствии с требованиями ГОСТ 12.1.005-88 нормы характеризуется следующими параметрами: оптимальная температура воздуха в теплое время 20-23 °С, а в холодное время 22-25 °С; оптимальная относительная влажность воздуха в теплое время и в холодное время составляет 40-60 %; оптимальная скорость движения воздуха в холодное и в теплое время составляет 0,2 м/с. Также есть и критерий допустимой температуры воздуха в теплое время на 3 больше максимальной (Т годовой), в холодное время 19-25 °С; допустимой относительной влажности воздуха в теплое время 55 %, в холодное время 40-75 %; допустимая скорость движения воздуха в холодное 0,2-0,5, в теплое время составляет 0,2 м/с.
- Требования к составу и параметрам технических средств
Система должна работать на IBM совместимых персональных компьютерах.
Минимальная конфигурация:
- тип процессора Pentium-100 и выше;
- объем оперативного запоминающего устройства 32 Мб и более;
- видео карта 32Мб;
- винчестер 2Гб.
- Требования к информационной и программной совместимости
Реализация поставленной задачи будет производиться с использованием:
- операционной системы Win32 (Windows 95, Windows 98, Windows 2000, Windows NT и т. п.);
- среды разработки Delphi 7.0.
4 ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
Разрабатываемые программные модули должны быть самодокументированны, т. е. тексты программ должны содержать все необходимые комментарии.
В состав документации должно входить руководство пользователю, руководство программиста.
5 ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ
Внедренная разработанная автоматизированная система позволит:
- сократить время;
- повысить эффективность обработки информации.
6 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ
Жизненный цикл программного изделия:
- Основные процессы:
1.1 приобретение;
1.2 поставка;
1.3 разработка;
1.4 эксплуатация;
1.5 сопровождение.
- Организационные процессы:
2.1 управление;
2.2 усовершенствование;
2.3 создание инфраструктуры;
2.4 обучение.
3. Вспомогательные процессы:
3.1 документирование;
3.2 управление конфигурацией;
3.3 обеспечение качества;
3.4 аттестация;
3.5 совместная оценка;
3.6 аудит;
3.7 разрешение проблем.
7 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ
Существуют следующие виды испытания программного обеспечения – стендовые – на макете, полигонные – на конкретном рабочем месте. В данном случае выбирается полигонный вид испытания. Испытание и приемка производится в присутствии двух сторон – заказчик и разработчик, с подписанием акта приема передачи. Сопровождение программного обеспечения на усмотрение заказчика.
2.2 Разработка модели использования для системы «Видеопрокат»
Поведение разрабатываемой системы описывается с помощью функциональной модели, которая отображает системные прецеденты (use case), системное окружение (actors) и связи между прецедентами и актерами (use case diagrams). Основная задача модели прецедентов – представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Разработка модели прецедентов начинается на стадии задумки с выбора актеров и определения общих принципов функционирования системы. Затем на этапе проработки модель дополняется детальной информацией к существующим прецедентам, а при необходимости добавляются новые.
Прецедент выполняет функции диалога между системой и актером. Набор всех прецедентов системы определяет способы ее использования. Актеры представляют собой независимые субъекты, взаимодействующие с системой. Они могут снабжать информацией или получать ее из системы.
На рисунке 1 показана диаграмма прецедентов, в которой выделяются пять актеров Покупатель, Кассир, Менеджер по продажам, Склад, Товаровед и множество взаимосвязанных с ними прецедентов.
Рисунок 1 - Диаграмма прецедентов для системы «Видеопрокат»
Диаграмма использования наглядно показывает актеров и их основные действия для проектируемой системы.
Таблица 1 – Актеры, прецеденты и требования проектируемой системы
Актёр |
Прецедент |
Требования |
Клиент |
Выбор видео; |
Просматривает имеющиеся в наличие видео |
Оплата видео; |
Оплачивает видео которое берет на прокат | |
Консультант |
Изучение видео; |
Знание о кратком содержании видео |
Помощь клиентам в выборе видео; |
Дает информацию о новинках и кратко описывает видео | |
Оператор |
Получение денег; |
Берет оплату за видео у клиента |
Выдача на прокат видео; |
Клиенту выдает видео | |
Информация о видео; |
Заносит в БД поступившие видео продукции и фиксирует видео которое на руках у клиентов | |
Информация о клиентах; |
Заносит информацию о видео которое берет и возвращает клиент, подсчет количества взятых видео клиентом | |
Регистрация и выдача индивидуальной карты клиентам; |
Вводит паспортные данные нового клиента, присваивает индивидуальный номер клиенту и выдает карточку с этим номером | |
Поставщик |
Изучение продукции; |
Следит за новостями появления новых фильмов и спросом на них |
Поставка продукции; |
Покупает видео и поставляет в магазин «Видеопрокат» |
2.3 Построение концептуальной модели «Товарооборот и обработка платежей в магазине видеопроката»
2.3.1 Описание поведения системы
Каждый прецедент должен быть описан с помощью документально зафиксированного потока событий (flow of events). Соответствующий текстовый документ (см. таблица 1) определяет, что должна делать система, когда субъект инициирует прецедент.
Таблица 2 – Описательная спецификация прецедента «Выбор видео»
Прецеденты |
Оформление платежа |
Продолжение таблицы 2
Краткое описание |
Прецедент позволяет уточнить какое видео надо |
Субъекты |
Клиент |
Предусловия |
Оператор определяет наличие видео |
Основной поток |
Начало прецедента совпадает с окончательным выбором видео |
Альтернативный поток |
В случае если такого видео нет, то оператор предлагает другое видео |
Постусловие |
Если прецедент был успешным, заказ на прокат видео заносится в компьютер |
2.3.1.1 Диаграмма последовательностей системы
Диаграмма последовательности действий (sequence diagrams) отображает взаимодействие объектов, упорядоченное по времени. На ней показаны объекты и классы, используемые в сценарии, и последовательность сообщений, которыми обмениваются объекты, для выполнения сценария. Диаграммы последовательности действий обычно соответствуют реализациям прецедентов в логическом представлении системы.
Диаграмма последовательности действий используется для просмотра сценария во временном порядке: что происходит сначала, что происходит затем. Диаграмма взаимодействий представляет общую картину сценария. Такой тип диаграмм чаще используют на этапе проектирования, когда планируется реализация отношений.
Диаграмма последовательности действий для автоматизированной системы взятия видео на прокат показана на рисунке 2.
Рисунок 2 - Диаграмма последовательности действий для системы «Видеопрокат»
Клиент придя в видеопрокат консультируется у консультанта, узнавая какие фильмы есть у них. Консультант делает запрос о наличии видео оператору, а оператор дает ему всю информацию о видео которое есть в данный момент в магазине. Выбрав видео, клиент берет его на прокат, сообщая консультанту, а консультант сообщает информацию, о выбранном видео клиентом, оператору. Клиент производит расчет с оператором, если у него есть индивидуальная карта, в которой фиксируются количество взятых видео клиентом, то оператор производит по ней выдачу видео. Если же оказалось, что у клиента нет такой карты, то оператор сначала заносит данные клиента в БД, а потом при выдаче видео клиенту дает ему эту карту. В конце операции клиент получает видео, индивидуальную карту и чек.
2.3.1.2 Диаграммы кооперации
Диаграмма кооперации (collaboration diagrams) – это альтернативный способ отображения сценариев. Такой тип диаграммы показывает взаимодействие объектов, организованное вокруг них, и их связи друг с другом.
Диаграмма коопераций для системы учет товара в магазине показана на рисунке 3.
Рисунок 3 - Диаграмма коопераций для системы «Видеопрокат»
На данной диаграмме отображено взаимодействие объектов и связи между ними.
2.3.1.3 Диаграммы действий
Диаграммы действий отражают динамику проекта и представляют собой схемы потоков управления в системе от действия к действию, а также параллельные действия и альтернативные потоки.
В конкретной точке жизненного цикла диаграммы действий могут представлять потоки между функциями или внутри отдельной функции. На разных этапах жизненного цикла они создаются для отражения последовательности выполнения операции.
Диаграммы действий иллюстрируют действия, переходы между ними, элементы выбора и линии синхронизации.
Диаграмма действий для проектируемой системы представлена на рисунке 4.
Рисунок 4 - Диаграмма действий для системы «Видеопрокат»
На данной диаграмме показано последовательность действий при взятие видео на прокат.
Рассмотрим события, относящиеся к основному и альтернативным потокам, заимствованным из документа описания прецедента, а также состояния видов деятельности.
Таблица 3 - Установление действий в основном и альтернативных потоках
п/п |
Формулировка прецедента |
Состояние вида деятельности |
1 |
Клиент приходит в видеопрокат и выбирает видео |
Выбор видео |
2 |
Консультант дает информацию о видео |
Консультация о видео |
3 |
Консультант делает запрос оператору о наличии видео |
Запрос о наличии видео |
4 |
Оператор дает консультанту информацию о видео |
Информация о видео |
Продолжение таблицы 3
5 |
Консультант дает оператору информацию о видео, которое выбрал клиент. Оператор регистрирует клиента и видео в БД |
Регистрация клиента и выбранное видео в БД |
6 |
Оператор берет у клиента индивидуальную карту, в которой фиксируется кол-во раз взятых видео. Если у клиента она есть, то он оплачивает видео |
Оплата видео |
7 |
Если у клиента нет карты, то его регистрируют с наличием паспорта и только потом выдают карту |
Выдача карты |
8 |
После чего клиент оплачивает видео |
Оплата видео |
9 |
После оплаты видео клиент берет видео и чек |
Выдача видео и чека |
2.3.2 Разработка структуры программного
обеспечения
2.3.2.1 Определение отношений между объектами
Класс (class) - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта. Каждый объект является экземпляром конкретного класса и не может быть экземпляром нескольких классов.
Ассоциация (association) – это двунаправленная семантическая связь между классами (данные могут поступать в обоих направлениях).
Агрегационное отношение (aggregation) – это специальная форма ассоциации между целым и его частью или частями. Агрегация известна как отношение «часть от» или «содержит».
Отношение использования (dependency) между классами соответствует равноправной связи между их экземплярами. Это то, во что превращается ассоциация, если оказывается, что одна из ее сторон пользуется услугами другой.
Обобщение (generalization) позволяет создавать суперклассы, объединяющие общие для нескольких классов структуру и поведение.
Диаграмма классов для проектируемой системы учет товара в магазине представлена на рисунке 5.
Рисунок 5 - Диаграмма классов для автоматизированной системы «Видеопрокат»
Таблица 4 - Описание отношений между классами в системе «Видеопрокат»
Начальный класс |
Тип отношения |
Кратность |
Конечный класс |
Консультант |
Ассоциация |
1 – 1…n |
Оператор |
Оператор |
Ассоциация |
1 – 0…n |
Прокат |
Продолжение таблицы 4
Клиент |
Ассоциация |
1–0…n |
Прокат |
Прокат |
Агрегация |
1..n – 0…n |
Диски |
Склад |
Агрегация |
1– 0…n |
Диски |
Аудио Видео |
Обобщение |
Диски | |
Консультант |
Ассоциация |
1..n - 1 |
Склад |
2.3.2.2 Проектирование классов
Атрибуты используются в анализе и проектировании для выражения отдельных свойств класса. Операции и атрибуты представляют собой прообраз полной спецификации класса, в которой объявляются все его элементы.
Диаграммы классов (class diagrams) помогают графически представить классы в модели (см. рис. 6 диаграмма классов для системы «Видеопрокат»).
Рисунок 6 - Диаграмма классов для системы «Видеопрокат»
На данной диаграмме показана структура объектов. Атрибуты классов представлены в таблице.
Таблица 2.5 Описание классов системы
Наименование класса |
Тип класса |
Название атрибутов |
Тип атрибута |
Операции |
Оператор |
Entity - Сущность |
ID |
Integer |
Работа с клиентом |
Имя |
String |
Оформление проката | ||
Клиент |
Entity - Сущность |
Информация |
String |
Выбор видео |
Оплата | ||||
Прокат |
Entity - Сущность |
ID товара |
Integer |
Наличие взятых на прокат |
Наименование |
String | |||
Количество |
Integer | |||
Стоимость |
Integer | |||
Дата |
Date | |||
Диски |
Entity - Сущность |
ID |
Integer |
Убытие |
Наименование |
String | |||
Количество |
Integer |
Пополнение | ||
Стоимость |
Integer | |||
Дата |
Date | |||
Аудио |
||||
Видео |
||||
Консультант |
Entity - Сущность |
ID |
Integer |
Контроль |
Склад |
Boundary-Граничный |
ID видио |
String |
Хранение |
Пополнение |

- Информационная система в логистике
- Информационная система в сервисе
- Информационная система в управлении предприятием
- Информационная система в экономике
- Информационная система ГАИ
- Информационная система гостиница
- Информационная система "Гостиница"
- Информационная система fidelio
- Информационная система автомобилестроительного предприятия
- Информационная система агентство недвижимости
- Информационная система: "Антиквариат"
- Информационная система аптеки
- Информационная система "Библиотека"
- Информационная система библиотеки