Файл: Автоматизация учёта арендованных средств для ИП Сумин.pdf
Добавлен: 31.03.2023
Просмотров: 329
Скачиваний: 1
СОДЕРЖАНИЕ
1. Технико-экономическая характеристика предметной области и предприятия
1.1. Характеристика предприятия и его деятельности
1.2. Организационная структура управления предприятием
1.3. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов
2. Информационное обеспечение задачи
2.1 Информационная модель и её описание
2.2 Характеристика нормативно-справочной, входной и оперативной информации
3. Программное обеспечение задачи
3.1 Общие положения (дерево функций и сценарий диалога)
3.3 Структурная схема пакета (дерево вызова программных модулей)
2. Информационное обеспечение задачи
2.1 Информационная модель и её описание
CA ERwin Process Modeler (старое название – BPwin) представляет собой мощное case - средство моделирования, которое поддерживает моделирование процессов (методология IDEF0), моделирование потоков данных (методология DFD) и моделирование технологических процессов (методология IDEF3). Наиболее популярной методологией IDEF является методология IDEF0. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique — Техника структурного анализа и дизайна). В России приняты официальные рекомендации по применению методологии IDEF0.
Целью методологии является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. Другими словами, в IDEF0 моделируемая система представляется как совокупность взаимосвязанных работ (функций, активностей). Методология IDEF0 получила столь широкое распространение в бизнес-моделировании потому, что эта методология легко представляет такие системные характеристики, как управление, обратная связь, исполнители. Кроме того, методология IDEF0 имеет развитые процедуры поддержки коллективной работы. В основе методологии лежат четыре основных понятия: функциональный блок, дуга (стрелка), декомпозиция, глоссарий.
Таким образом, любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую дугу и одну исходящую. То есть каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет смысла.
В соответствии с целями и задачами, сформулированными для данной информационной системы для компании по аренде транспортных средств на рисунке 3 представлена общая функциональная модель этой системы.
Рисунок 3– Общая функциональная модель информационной системы
Ведением информации в системе занимается администратор, который добавляет информацию о новых автомобилях и редактирует данные текущих автомобилях.
Менеджер осуществляет обработку поступивших заявок от клиентов, добавляет новые документы от клиентов в БД и производит их проверку с помощью автоматизированного модуля.
Арендатор обращается в компанию и тем самым создает заявку на аренду автомобиля, которая фиксируется в системе и переходит к менеджеру на обработку.
Назначение привилегий доступа к определенным модулям производится через систему авторизации, на основе которой происходит аутентификация пользователя, и определяются возможности каждого пользователя.
Для разработки модели процессов автоматизированной системы учёта проката автомобилей использовалось CA ERwin Process Modeler версии 7.3. Модель разработана на основе смешанной методологии. Контекстная диаграмма разработана на основе методологии IDEF0 и представлена бизнес - процессом «Учет информации об аренде автомобилей» на основе материалов исследования (рисунок 4).
Рисунок 4 - Контекстная диаграмма системы
Выполнение бизнес-процесса «Учет информации об аренде автомобилей» выполняется с помощью ресурсов: менеджер, автомеханик, бухгалтер, администратор системы согласно уставу фирмы и закону о защите прав потребителей.
2.2 Характеристика нормативно-справочной, входной и оперативной информации
Декомпозиция процесса «Учёт информации об аренде автомобилей» проводилась на основе методологии DFD. В результате декомпозиции бизнеспроцесса «Учёт информации об аренде автомобилей» на основе анализа предметной области выделено 5 бизнес-процессов:
– оформление заказов;
– учет информации об автомобилях;
– учет информации о расчетах;
– учет данных о сотрудниках;
– учет информации о клиентах.
Для отображения накапливаемых данных определено четыре хранилища:
– клиенты;
– автомобили;
– договоры;
– сотрудники.
Процесс «Учет информации о клиентах» предназначен для сбора, обработки, хранения и предоставления информации о клиентах.
Входными данными процесса «Учет информации о клиентах» является анкета клиента.
Выходными данными бизнес-процесса «Учет информации о клиентах» являются данные клиентов, предназначенные для хранилища «Клиенты».
Процесс «Оформление заказов» предназначен для сбора, обработки, хранения и предоставления информации о заказах на аренду автомобилей, оформленных договорах.
Входными данными процесса «Оформление заказов» являются:
- информация о клиенте, поступающая из хранилища «Клиенты»;
- данные автомобилей, поступающие из хранилища «Автомобили»;
- данные сотрудника, оформляющего договор, поступают из хранилища «Сотрудники»;
- заявка на автомобиль.
Выходными данными процесса являются:
- информация о договорах, поступающая в хранилище «Договоры»
- отчет по не оплаченным договорам;
- договор аренды автомобиля.
Процесс «Учет информации об автомобилях» предназначен для сбора, обработки, хранения и предоставления информации об автомобилях.
Входными данными процесса «Учет информации об автомобилях» являются:
- информация об автомобилях в наличии;
- результаты осмотра возвращенного автомобиля.
Выходными данными процесса являются:
- прайс лист;
- карточка автомобиля.
Процесс «Учет информации по расчетам» предназначен для сбора, обработки, хранения и предоставления финансовой информации по аренде автомобилей.
Входными данными процесса «Учет информации по расчетам» являются:
- платежный документ;
- данные о сделках, поступающие из хранилища «Договоры».
Выходными данными процесса является отчет по взаиморасчетам.
Процесс «Учет информации по сотрудникам» предназначен для сбора, обработки, хранения и предоставления информации о сотрудниках фирмы, зарегистрированных в системе.
Входными данными процесса «Учет информации по сотрудникам» являются данные сотрудника.
Выходными данными процесса является информация о сотрудниках, поступающая в хранилище «Сотрудники».
Процессы, выделенные в результате декомпозиции, являются элементарными для понимания и разработки приложения и соответственно не требуют дальнейшей декомпозиции.
Диаграмма, полученная в результате декомпозиции процесса «Учет информации об аренде автомобилей», представлена на рисунке 5.
Рисунок 5 - Модель бизнес-процесса «Учет информации об аренде автомобилей»
3. Программное обеспечение задачи
3.1 Общие положения (дерево функций и сценарий диалога)
Назначение и средство разработки модели данных системы. AllFusion ERwin Data Modeler — CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данныхпомогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.
AllFusion ERwin Data Modeler предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. AllFusion ERwin Data Modeler позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.
AllFusion ERwin Data Modeler позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion ERwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоёмких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.
В процессе логического проектирования модели данных автоматизированной системы учета проката автомобилей определены 13 сущностей, выделены их атрибуты, определены мощности связей между ними и проведена нормализация отношений до третьей нормальной формы (3НФ). Описание сущностей представлено в таблицах 1 — 13.
Таблица 1 - Описание сущности «Клиент»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID клиента |
PK |
Недопустимо |
ФИО |
Недопустимо |
|
Адрес |
Недопустимо |
|
Телефон |
Недопустимо |
|
Место работы |
Недопустимо |
|
Номер паспорта |
Недопустимо |
|
Номер водительского удостоверения |
Недопустимо |
Таблица 2 - Описание сущности «Автомобиль»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Автомобиля |
PK |
Недопустимо |
ID Марки |
PK, FK |
Недопустимо |
ID Модели |
PK, FK |
Недопустимо |
Гос. номер |
Недопустимо |
|
Год выпуска |
Недопустимо |
|
ID Обивки салона |
PK, FK |
Недопустимо |
ID Цвет кузова |
PK, FK |
Недопустимо |
ID Объем двигателя |
PK, FK |
Недопустимо |
Таблица 3 — Описание сущности «Марка»
Имя атрибута |
Ключевой параметр |
Назначение |
ID Марки |
РК |
Недопустимо |
Наименование |
Недопустимо |
Таблица 4 — Описание сущности «Модель»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Модели |
РК |
Недопустимо |
ID Марки |
PK, FK |
Недопустимо |
Наименование |
Недопустимо |
Таблица 5 — Описание сущности «Обивка салона»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Обивки салона |
РК |
Недопустимо |
Наименование |
Недопустимо |
Таблица 6 — Описание сущности «Цвет кузова»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Цвета кузова |
РК |
Недопустимо |
Наименование |
Недопустимо |
Таблица 7 — Описание сущности «Объем двигателя»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Объема двигателя |
РК |
Недопустимо |
Наименование |
Недопустимо |
Таблица 8 — Описание сущности «Сотрудник»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Сотрудника |
РК |
Недопустимо |
ФИО |
Недопустимо |
|
Должность |
Недопустимо |
Таблица 9 — Описание сущности «Результат осмотра автомобиля»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Результата |
РК |
Недопустимо |
ID Сотрудника |
FK |
Недопустимо |
ID Автомобиля |
FK |
Недопустимо |
Наличие повреждений |
Недопустимо |
Таблица 10 — Описание сущности «Прайс-лист»
Имя атрибута |
Ключевой параметр |
Нулевое значение |
ID Прайса |
РК |
Недопустимо |
ID Автомобиля |
PK, FK |
Недопустимо |
Дата |
Недопустимо |
|
Стоимость часа проката |
Недопустимо |