Автоматизации работы автобусного парка

Введение

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

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

На современном этапе развития информатизации и автоматизации характерно применение распределенной обработки информации. В качестве более эффективной и перспективной сферы применения концепции распределенной обработки информации выступает автоматизация планово-управленческих функций на основе персональных компьютеров, которые установлены непосредственно на рабочем месте того или иного специалиста. Системы, которые выполняют данные функции, наделены широким распространением, которые называются как автоматизированные рабочие места (АРМ). 1 Все вышесказанное обуславливает актуальность выбранной нами темы.

Предметом исследования выступает специфика автоматизированной информационной системы учета для расчёта заработной платы. В качестве объекта исследования выступает транспортная компания «АБУС-транс».

При этом отметим, что рассматриваемая нами компания, а именно транспортная компания «АБУС-транс» это многопрофильная компания. К основным направлениям ее деятельности можно отнести следующее:

— заказ автобуса и микроавтобуса;

— городские грузоперевозки;

— квартирные и офисные переезды, услуги грузчиков;

— аренда спецтехники;

— эвакуация легковых автомобилей.

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

— Водитель

— Бухгалтер

— Депо

— Диспетчер

— Кондуктор Цель данного исследования заключается в разработке информационной системы «Расчет зарплаты» для компании «АБУС-транс». Для достижения поставленной нами цели, необходимо решить ряд задач, а именно:

— провести системный анализ и анализ требований

— рассмотреть модель прецедентов

— рассмотреть модель предметной области

— рассмотреть модель проектирования

— рассмотреть модель данных

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

1. Системный анализ и анализ требований алгоритм запрос таблица макрос Перед тем как перейти к системному анализу и анализу требований, отметим, что в качестве объекта исследования являлась транспортная компания «АБУС-транс».

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

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

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

Рисунок 1.1

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

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

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

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

В таблице 1.1 представлены вопросы и ответы из проведенного интервью с бухгалтером.

Таблица 1.1 Сбор требований способом «интервью»

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

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

Схема, позволяющая определить рамки системы представлена на рисунке 1.2

Рисунок 1.2 — Рисунок системы Перечень исполнителей и их задач представим в таблице 1.2

Таблица 1.2 Исполнители и их задачи

Также рассмотрим перечень исполнителей и их задач на основе анализа внешних событий. (см. таблицу 1.3)

Таблица 1.3

Перечень исполнителей и их задач на основе анализа внешних событий

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

Теперь постараемся изобразить диаграмму прецедентов и их описание, на основании нашего исследования. (см. рисунок 1.3)

Рисунок 1.3 — Диаграмма прецедентов Описание прецедентов Прецедент П1: Подсчет прибыли.

Основной исполнитель: Бухгалтер.

Заинтересованные лица и их требования:

Кондуктор: Хочет в начале и в конце каждого рабочего дня знать количество билетов, выданных диспетчером, и соответственно оставшихся.

Бухгалтер: Хочет подсчитать полученную прибыль от продажи билетов и распределить ее на оплату налогов и зарплаты.

Предусловия: Бухгалтер должен быть идентифицирован и аутентифицирован.

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

Основной, успешный сценарий:

1).В начале рабочего дня бухгалтер фиксирует в «журнале учета»: дату, количество выдающихся билетов, в соответствии с маршрутом; выдает билеты диспетчеру, который передает кондуктору.

2).В конце рабочего дня кондуктор возвращает диспетчеру оставшееся количество билетов и сумму от проданных. Диспетчер передает их бухгалтеру, который заносит всю необходимую информацию (дата, №маршрута, количество оставшихся билетов, количество выданных билетов, сумма) в «журнал учета».

3).Бухгалтер учитывает образовавшуюся прибыль и высчитывает денежные финансы на оплату налогов и заработной платы. А также, фиксирует количество денежных финансов на налоги в «журнале налогов», а заработную плату в «журнале ЗП».

Альтернативный сценарий 1:

2.а). В конце рабочего дня кондуктор возвращает диспетчеру всё оставшееся количество билетов, но не всю сумму денег за проданные билеты.

1. Диспетчер передает все бухгалтеру. Бухгалтер заносит всю необходимую информацию в систему.

2. Система при подсчете обнаруживает ошибку недостачи, а также количество штрафа.

3. Бухгалтер вызывает кондуктора и информирует его о недостаче. Кондуктор платит необходимую сумму штрафа, по ранее определенной сумме. Бухгалтер заносит заплаченную сумму штрафа в «журнал штрафов».

4. Бухгалтер заносит в систему уже новые данные. Переход к п. 1).

Прецедент П2: Распределение транспорта по маршрутам.

Основной исполнитель: Диспетчер.

Заинтересованные лица и их требования:

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

Водитель: Хочет иметь в наличии маршрут своего транспорта, путевой лист, расписание остановок, точное время передвижения и остановок.

Предусловия: Диспетчер должен быть идентифицирован и аутентифицирован.

Постусловия: Транспорт распределен по маршрутам.

Основной, успешный сценарий.

1).Диспетчер создает путевые листы в системе для всех необходимых маршрутов, в зависимости от количества мест, приходящихся на каждый транспорт, и количеством пассажиров на маршрутах. Все путевые листы хранятся в «журнале П_лист'.

2).В начале рабочего дня диспетчер выдает каждому водителю его путевой лист. Диспетчер отправляет транспорт по маршруту. Регистрирует начало каждого маршрута в «журнале регистрации отправки и прибытия транспортов».

3).Диспетчер принимает транспорт, проверяет его, и не найдя повреждений отпускает водителя, регистрирует в «регистрации отправки и прибытия транспортов», а также сообщает системе о завершении определенного маршрута.

Альтернативный сценарий 1:

3.а) В конце рабочего дня транспорт не возвращается в Депо

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

2. При прибытии с маршрута транспорта переход к п. 3).

Альтернативный сценарий 2:

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

1. Диспетчер сообщает о повреждениях водителю, в Депо, в систему в «журнал повреждений».

2. Транспорт снимают с линии маршрута, заменяя его другим и фиксируя смену в системе.

3. Депо вызывает мастера по ремонтным работам, регистрируя в системе оплату работнику за ремонт.

4. После ремонта транспорт возвращают на линию маршрута. Переход к п. 3).

Прецедент П3: Расчет с работниками.

Основной исполнитель: Бухгалтер.

Заинтересованные лица и их требования:

Бухгалтер. Хочет точно и быстро выделить средства для оплаты услуг работников.

Руководство. Хочет аккуратно и точно записать и хранить информацию о выделенных средствах в систему.

Предусловия: Бухгалтер идентифицирован и аутентифицирован (имеет доступ к определенным ресурсам). Программа загружена.

Постусловия: Расчет с работниками. Занесение и сохранение соответствующей информации в журналах системы.

Основной, успешный сценарий

1).В систему бухгалтером заноситься количество выданных билетов и количество оставшихся, за весь месяц.

2).Система считает прибыль от всех проданных билетов. Бухгалтер отсчитывает некоторую часть прибыли на оплату налогов, заносит в «журнал налогов».

3).Система вычисляет заработную плату работникам в соответствии с установленным коэффициентом k, который (от всей суммы прибыли) составляет:

— для водителя = 0,3

— для кондуктора = 0,15

— для диспетчера = 0,15

— для бухгалтера =0,2

5).Система выводит конечные данные по оплате и сохраняет их. Бухгалтер расплачивается с работниками, фиксируя все расчеты в «журнале ЗП».

Альтернативный сценарий 1:

1.а). В систему бухгалтер заносит не всю информацию.

1. Бухгалтер заносит только количество выданных билетов.

2. Система выдает сообщение: «НЕДОСТАТОЧНО ДАННЫХ ДЛЯ РАСЧЕТА!!!»

3. Бухгалтер вводит уже всю информацию заново. Переход к п. 1.

Прецедент П4: Расчет с поставщиком электроэнергии.

Основной исполнитель: Бухгалтер.

Заинтересованные лица и их требования:

Бухгалтер. Хочет точно и быстро выделить средства для оплаты услуг энергопоставщика.

Руководство. Хочет аккуратно и точно записать в систему, и хранить информацию о выделенных энергопоставщику средствах.

Предусловия: Бухгалтер идентифицирован и аутентифицирован (имеет доступ к определенным ресурсам). Программа загружена.

Постусловия: Произведен расчет за электроэнергию. Занесение и сохранение соответствующей информации в базе данных системы.

Основной, успешный сценарий:

1).Бухгалтер заносит все необходимые данные (количество маршрутов, пройденные ими расстояния) в систему.

2).Система в конце каждого дня производит подсчет затраченной электроэнергии на каждый маршрут, соответственно учитывая расстояния маршрутов. Бухгалтер сохраняет в системе все данные в конце каждого дня.

3).В конце каждой недели бухгалтер суммирует окончательный результат за оплату электроэнергии. Бухгалтер сохраняет в системе все данные в конце каждой недели.

4).Бухгалтер представляет полученный отчет поставщику электроэнергии. Поставщик сверяет со своими расчетами, и при совпадении принимает оплату. Бухгалтер фиксирует в системе все проведенные расчеты и уплаты в «журнале оплаты за электричество».

Альтернативный сценарий 1:

4).Не совпадение расчетов бухгалтера и поставщика.

1. Бухгалтер заново вносит свои данные в систему. Система выдает новые данные об оплате.

2. Бухгалтер представляет новый полученный отчет поставщику электроэнергии. Переход к п4).

Дополнительная спецификация.

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

Описание требования заказчика осуществляется на основе 4-х категорий. Категории представим и опишем в таблице 1.4.

Таблица 1.4 Категории описания требований

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

Таблица 1.5 Функциональные требования

В качестве второй категории в описании требований выступает категория системных требований, — S. Описание системных требований представим в таблице 1.6.

Таблица 1.6 Системные требования

Требования к представителю (Р) относятся к третьей категории. Они описывают формирование требований заказчика к интерфейсу программного обеспечения. Описание требований к предоставлению показаны в таблице 1.7.

Таблица 1.7 Требования к предоставлению

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

Таблица 1.8 Требования к рискам

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

Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту.

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

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

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

Заинтересованные лица:

Водитель: хочет осторожно и точно по расписанию производить маршрут.

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

Депо: хочет, в случае необходимости производить ремонт — амортизацию транспорта.

Кондуктор: хочет зафиксировать в начале каждого маршрута количество билетов, выданных диспетчером, а также подсчитать их количество в конце маршрута.

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

Место системы.

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

Пользователи системы.

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

Задачи и свойства системы.

Обеспечивать удобный интерфейс пользователя.

Реагировать на ошибки ввода — вывода данных.

Искать данные в системе по запросу.

Словарь терминов:

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

При этом отметим список категорий концептуальных классов. (см. таблица 2.1.)

Таблица 2.1 Список категорий концептуальных классов

Описание концептуальных классов.

Бухгалтер — Accountant

Пассажир — Passenger

Водитель — Driver

Диспетчер — Dispatch

Кондуктор — Conductor

Депо — Depo

Служба авторизации платежей — Service payment

Амортизационный фонд — Repair fund

Билет — Ticket

Налог — Tax

Прибыль — Profit

Заработная плата — Salary

Трамвай — Tram

Троллейбус — Trolley-bus

Путевой лист — Plist

Продажа — Sale

Оплата — Payment

Маршрут — Itinerary

Расписание — Time_table

Налоговая служба — Tax_Service

Энергопоставщик — ElSupplier

Журнал регистрации транспорта — Journal transport register

Журнал путевых листов — Journal_Plist

Журнал учета — Journal_Ychet

Журнал ЗП (Заработной платы) — Journal_ZP

Журнал налогов — Journal_Tax

Журнал оплаты за электроэнергию — Journal_Elect

Журнал штрафов — Journal_sh

Журнал повреждений — Journal_break

Таблица 2.2 Ассоциации классов

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

Рисунок 2.1 — Диаграмма концептуальных классов Атрибуты классов

Itinerary

Name It-ry: text

Col. Stop: int

Name Stop: text

time between Stop: double

time A: double

time B: double

alary

Summa: double

Col sale ticket: double

Bonus: double

Tax: double

Procent: double

Holiday: double

PList

Number T-t: int

Itinerary: text

Time A: double

time B: double

surname Driver: text

year: double

month: double

Accountant

name: FIO

addres: text

tel: Phone Number

Transport_Register

Surname_Dispatch: text

NumberIt-ry: double

Number_Tr-t: double

Time A: double

Time B: double

Transport

Tip: text

Number: int

Ser_number: int

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

При этом, на основании нашего исследования, отметим следующее:

Прецедент: Распределение транспорта по маршрутам.

Описание операции ОП 1 Таблица 3.1

Рисунок 3.1 Прецедент: Начисление заработной платы Описание операции ОП 2 Таблица 3.2

Рисунок 3.2

Таблица 3.3 Описание операции ОП 3

Рисунок 3.3 Прецедент: Оплата за электроэнергию Таблица 3.4 Описание операции ОП 4

Рисунок 3.4

Программные классы

Journal_Plist

FIO_driver: String

FIO_cond: String

№marsh: Byte

data: Byte

№Plist: Byte

Plist (№marsh, data, №Plist, FIO_driver, FIO_cond)

Journal_Ychet

data: Byte

colvo_t № 1: Byte

colvo_t № 2: Byte

№marsh: Byte

sum: Byte

Beginwork_day (data, colvo_t № 1, №marsh)

Endwork_day (data, colvo_t № 1, colvo_t № 2, sum, №marsh)

Journal_ZP

pribul: Byte

sumZP: Byte

zp: Byte

zp_account: Byte

zp_driv: Byte

zp_disp: Byte

zp_cond: Byte

Podschet_ZP (pribul, sumZP)

Pay_ZP (zp, zp_account, zp_driv, zp_disp, zp_cond)

Journal_transport register

data: Byte

№marsh: Byte

timeA: Byte

timeB: Byte

Begin_marsh (data, №marsh, timeA)

End_marsh (data, №marsh, timeB)

Journal_sh

№marsh: Byte

sum_sh: Byte

data: Byte

FIO: String

Shtraff (sum_sh, data, FIO, №marsh)

Journal_Tax

pribul: Byte

sumTax: Byte

data: Byte

Podschet_Tax (pribul, sumTax)

Pay_ZP (sumTax, data)

Journal_break

№marsh: Byte

data: Byte

Polomka (data, №marsh)

Journal_Elect

data: Byte

sum_el: Byte

El_oplata (data, sum_el)

System

FIO_driver: String

FIO_cond: String

№marsh: Byte

data: Byte

№Plist: Byte

colvo_t № 1: Byte

colvo_t № 2: Byte

sum: Byte

pribul: Byte

sumZP: Byte

zp: Byte

zp_account: Byte

zp_driv: Byte

zp_disp: Byte

zp_cond: Byte

data: Byte

timeA: Byte

timeB: Byte

sum_sh: Byte

FIO: String

pribul: Byte

sumTax: Byte

sum_el: Byte

time_now: Byte

№marsh_old: Byte

№marsh_new: Byte

sum_pay: Byte

all_prible: Byte

Plist (№marsh, data, №Plist, FIO_driver, FIO_cond), Beginwork_day (data, colvo_t № 1, №marsh), Endwork_day (data, colvo_t № 1, colvo_t № 2, sum, №marsh),

Podschet_ZP (pribul, sumZP), Pay_ZP (zp, zp_account, zp_driv, zp_disp, zp_cond),

Begin_marsh (data, №marsh, timeA), End_marsh (data, №marsh, timeB), Shtraff (sum_sh, data, FIO, №marsh), Podschet_Tax (pribul, sumTax), Pay_ZP (sumTax, data), Polomka (data, №marsh), El_oplata (data, sum_el), Otsyts_tr (FIO_driver, FIO_cond, data, time_now, №marsh), Zamena (№marsh_old, №marsh_new), Pay_break (sum_pay, data), Salary (all_prible, data)

4. Модель данных Рассматривая модель данных, отметим, что само понятие база данных (БД) представляет собой некую совокупность структурированных и взаимосвязанных данных и методов, обеспечивающих добавление выборку и отображение данных.

База данных — это единое, большое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями из разных подразделений.

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

Основными целями проектирования базы данных являются:

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

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

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

При создании базы данных проходят 3 этапа её разработки:

— концептуальное моделирование;

— логическое моделирование;

— физическое моделирование.

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

База данных является моделью части реального мира, которая представляет интерес для данного исследования. Часть реального мира, модель которой разрабатывается, называется предметной областью. Полнота описания предметной области зависит от целей создаваемой информационной системы. Для описания предметной области может использоваться естественный язык, но его использование имеет много недостатков. Наиболее важные — громоздкость описания, неоднозначность трактовки. Поэтому для этих целей используются формализованные языковые средства. Формализованное описание предметной области является концептуальной моделью.

Основными компонентами концептуальной модели являются:

Данные, циркулирующие в данной предметной области;

Описание классов, объектов предметной области и связей между ними;

Описание информационных потребностей пользователей.

Среди методов концептуального моделирования наибольшей популярностью пользуется ER-моделирование. ER-модель представляет собой графическое описание предметной области в терминах «объект-свойство-связь».

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

На рисунке 4.1 представлена диаграмма ER-типа, соответствующая рассмотренной диаграмме ER-экземпляров.

Рисунок 4.1 — Диаграмма ER-типа Пример концептуальной модели данных предметной области представлен на рисунке 4.2

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

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

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

При даталогическом моделировании необходимо спроектировать структуру таблиц с учетом требований к реляционным моделям в среде СУБД Access.

Обычно исходная реляционная модель формируется из ER-модели путем преобразования классов объектов и процессов в самостоятельные отношения — таблицы.

В результате моделирования может быть получена реляционная модель следующего вида:

КАДРЫ (Табельный номер, Фамилия, Имя, Отчество, Дата Рождения, Образовании) Должность (Код Должности, Название, Оклад, По Штату) Зарплата (ТабНомер, Фамилия, Имя, Отчество, Оклад, ДоплСложн, ДоплУдален, НадбКласс, Премия, НазваниеДолжн, Зарплата) ДоплатаСложность (КодСложн, Название, Надбавка) ДоплУдаленность (КодВредности, Название, Надбавка) Архив Удаленных (ТабНомер, Фамилия, Имя, Отчество, Дата Найма) НадбавкаКласс (КодКласс, Класс, Надбавка) Претенденты (КодПретед, ФИО, Образование, ДатаРождения, Адрес, На должность) На следующем этапе реализуется физическая модель в СУБД Access. Создаются таблицы классов объектов с соответствующими типами данных и свойствами полей.

Рисунок 4.3 — Структура таблиц с типами данных С помощью инструментальных средств в окнах Схема данных и Изменение связей устанавливаются связи между полями.

Рисунок 4.4 — Схема данных Рисунок 4.5 — Установка связи «один-ко-многим»

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

Рисунок 4.6 — Размер текстового поля «Название»

После создания всех полей и определения их свойств в таблицу можно вводить информацию. Для этого необходимо войти в режим таблицы. Новая таблица Access состоит из одной пустой записи. Чтобы её заполнить, необходимо ввести несколько строк с данными.

После ввода данных пустая запись смещается в конец таблицы.

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

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

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

С помощью клавиш Tab и Enter можно перемещаться по полям слева направо, а посредством клавиш Shift+Tab — в обратном направлении.

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

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

Также загрузка данных на этапе проектирования может производиться с помощью форм.

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

Рисунок 4.7 — Маска ввода для поля Дата Рождения

5. Модель реализации Реализация программного обеспечения — это процесс перевода системной спецификации в работоспособную систему. Итогом реализации приложения является работоспособная информационная система.

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

Реализация запросов средствами Access 2007:

Запрос, по удержаниям заработной платы (пример выполнения представлен на рисунке 5.1) — определяет именно тех сотрудников, у кого производится удержание заработной платы (Вид>Режим SQL):

Рисунок 5.1 — Пример выполнения запроса по удержаниям заработной платы

SELECT Сотрудники. Табельный №], Сотрудники. ФИО, Сотрудники. Должность, Сотрудники. Подразделение, [Учёт удержаний из зарплаты]. Вид удержания], [Учёт удержаний из зарплаты]. Сумма удержания (в %)]

FROM [Учёт удержаний из зарплаты] INNER JOIN ((Сотрудники INNER JOIN [Табель учёта рабочего времени] ON Сотрудники. Табельный №] = [Табель учёта рабочего времени]. Табельный № сотрудника]) INNER JOIN [Расчётно-платёжная ведомость] ON [Табель учёта рабочего времени]. № табеля] = [Расчётно-платёжная ведомость]. № табеля]) ON [Учёт удержаний из зарплаты]. Код удержания] = [Расчётно-платёжная ведомость]. Удержание зарплаты]

WHERE ((([Учёт удержаний из зарплаты]. Сумма удержания (в %)])>0))

ORDER BY [Учёт удержаний из зарплаты]. Сумма удержания (в %)];

Запрос, по стажу работы сотрудников (пример выполнения представлен на рисунке 5.2) — определяет именно тех сотрудников (и их стаж), которые удовлетворяют введённому пользователем значению в диалоговом окне (Вид>Режим SQL):

SELECT Сотрудники. Табельный №], Сотрудники. ФИО], Сотрудники. Год рождения], Сотрудники. Количество детей], Сотрудники. Должность], Сотрудники. Подразделение], Сотрудники. Образование], Сотрудники. Стаж работы]

FROM Сотрудники

WHERE (((Сотрудники. Стаж работы])=[Введите интересующий вас возраст]))

ORDER BY Сотрудники. ФИО];

Рисунок 5.2 — Пример выполнения запроса по стажу работы сотрудников Запрос для расчётно-платёжной ведомости (пример выполнения представлен на рис. 5.3). Данный запрос выводит полностью всех сотрудников (по запрашиваемому времени с помощью диалогового окна) с указанием всех рабочих часов, тарифных ставок, отпусков, премий, удержаний — и в итоге подсчитывает каждому зарплату — (Вид>Режим SQL). Так же с помощью данного запроса формируются отчёты по зарплате:

Рисунок 5.3 — Пример выполнения запроса для расчётно-платёжной ведомости

SELECT Сотрудники. Табельный №], Сотрудники. ФИО, Сотрудники. Должность, Сотрудники. Подразделение, [Тарифная сетка]. Тарифная ставка (руб)], [Табель учёта рабочего времени]. Дневные часы (часов)], [Табель учёта рабочего времени]. Ночные часы (часов)], [Табель учёта рабочего времени]. Праздничные часы (часов)], [Табель учёта рабочего времени]. Часов по болезни (часов)], [Табель учёта рабочего времени]. Часов по отгулам (часов)], Награждения. Сумма в %], [Учёт удержаний из зарплаты]. Сумма удержания (в %)], [Расчётно-платёжная ведомость]. Дата начисления], ((((([Табель учёта рабочего времени]![Дневные часы (часов)]*[Тарифная сетка]![Тарифная ставка (руб)])+(([Табель учёта рабочего времени]![Ночные часы (часов)]/10)*[Тарифная сетка]![Тарифная ставка (руб)])+([Табель учёта рабочего времени]![Праздничные часы (часов)]*2*[Тарифная сетка]![Тарифная ставка (руб)])-((([Табель учёта рабочего времени]![Часов по болезни (часов)]*70)/100)*[Тарифная сетка]![Тарифная ставка (руб)]))*[Награждения]![Сумма в %])/100)*[Учёт удержаний из зарплаты]![Сумма удержания (в %)])/100 AS Зарплата

FROM [Учёт удержаний из зарплаты] INNER JOIN ([Тарифная сетка] INNER JOIN ((Сотрудники INNER JOIN [Табель учёта рабочего времени] ON Сотрудники. Табельный №] = [Табель учёта рабочего времени]. Табельный № сотрудника]) INNER JOIN (Награждения INNER JOIN [Расчётно-платёжная ведомость] ON Награждения. Код премии] = [Расчётно-платёжная ведомость]. Премия сотруднику]) ON [Табель учёта рабочего времени]. № табеля] = [Расчётно-платёжная ведомость]. № табеля]) ON [Тарифная сетка]. Номер разряда] = [Расчётно-платёжная ведомость]. Номер разряда]) ON [Учёт удержаний из зарплаты]. Код удержания] = [Расчётно-платёжная ведомость]. Удержание зарплаты]

WHERE (((((((([Табель учёта рабочего времени]![Дневные часы (часов)]*[Тарифная сетка]![Тарифная ставка (руб)])+(([Табель учёта рабочего времени]![Ночные часы (часов)]/10)*[Тарифная сетка]![Тарифная ставка (руб)])+([Табель учёта рабочего времени]![Праздничные часы (часов)]*2*[Тарифная сетка]![Тарифная ставка (руб)])-((([Табель учёта рабочего времени]![Часов по болезни (часов)]*70)/100)*[Тарифная сетка]![Тарифная ставка (руб)]))*[Награждения]![Сумма в %])/100)*[Учёт удержаний из зарплаты]![Сумма удержания (в %)])/100)>0))

ORDER BY Сотрудники. ФИО;

Далее переходим в главное меню и выбираем пункт «Отчёты» и переходим в соответствующее меню. Нам на выбор предоставляется два отчёта по зарплате (они идентичны, но отличаются группировкой). При выборе пункта «…с группировкой по сотрудникам» на экран выводятся диалоговые окна с предложением ввести интересующую на дату.

Далее мы сможем вывести отчёт «…с группировкой по подразделениям" — ход выполнения тот же самый. Таким образом, работа с приложением завершена — из него можно выйти, выбрав в главном меню пункт «Выйти из приложения». Ниже на рисунке 5.4 приведена схема навигации диалога пользователя.

Рисунок 5.4 — Пример схемы навигации диалога пользователя Заключение В результате выполнения данного курсового проекта было разработано приложение для автоматизации работы автобусного парка. Данное приложение позволяет значительно упростить работу сотрудников ТК «АБУС-транс» (главным образом бухгалтера) и сэкономить время клиентов данной организации.

1. Автоматизация управления предприятием / В. В. Баронов, Г. Н. Калянов, Ю. Н. Попов и др. — М.: Инфра-М, 2010.

2. Автоматизированные информационные технологии в экономике / под ред. Г. А. Титоренко — М.: ЮНИТИ, 2011. — 400с.

3. Бойко В. В., Савинков В. М. Проектирование баз данных информационных систем. — М.: Финансы и статистика, 2010. — 351с.

4. Гребенюк Е. И., Гребенюк Н. А. Технические средства информатизации. — М.: Издательский центр «Академия», 2014. — 345с.

5. Ильина О. П. Информационные технологии бухгалтерского учета. — СПб.: Питер, 2011. — 688с.

6. Информационные технологии управления: Учебное пособие для ВУЗов под ред. Г. А. Титоренко — М.: ЮНИТИ-ДАНА, 2014. — 439с.

7. Кириллов В. В. Основы проектирования реляционных баз данных. Учебное пособие. — СПб.: ИТМО, 2014. — 90с.

8. Петров В. Н., Избачков Ю. С. Информационные системы 2-е издание.- СПб.: Издательский дом «Питер», 2005. 656 с.

9. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф. Проектирование экономических информационных систем: Учебник; Под. ред. Ю. Ф. Тельнова.- М.: Финансы и статистика, 2012.

10. Устинова Г. М. Информационные системы менеджмента/ Учебное пособие. — СПб: Изд-во «ДиаСофт ЮП», 2010. — 368 с.

11. Уткин В. Б., Балдин К. В. Информационные системы в экономике — М.: Финансы и статистика, 2014. — 335с.

12. Шафрин Ю. Информационные технологии — М.: Издательство: «Бином. Лаборатория знаний», 2012. — 336с.

Приложение Приложение 1

Спецификация требований к программному обеспечению Назначение Эта спецификация требований описывает функциональные и нефункциональные требования для разрабатываемой АИС «Расчёт зарплаты» для ТК «АБУС-транс» г. Пермь. Система предназначена для расчёта заработной платы по временной системе оплаты труда и вывода отчёта в виде расчётного листка. Цель Итоговой целью разработки является разработка автоматизированной информационной расчёта заработной платы «Расчёт зарплаты».

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

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

— ведение базы данных личных дел сотрудников предприятия;

— расчёт налога на доход физических лиц.

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

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

Классы и характеристики пользователей В таблице приведены основные категории пользователей, использующих проектируемую ИС.

Общие ограничения Операционная среда-1.Минимальные требования к операционной системе — Windows XP SP2. Ограничения дизайна и реализации-1. База данных должна быть спроектирована на MySQL 5.1.40.

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

Требования к внешнему интерфейсу Интерфейсы пользователя-1. Экраны вывода должны соответствовать общепринятым стандартам.

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

Требования к производительности Требования к производительности-1.Обмен между приложением и БД должен осуществляться с задержками ответа на запрос не более 7 сек.

Требования к производительности-2.Формирование отчета должно производиться за время, приемлемое для непрерывной работы пользователя (не более 25 сек).

Требования к охране труда Требования к охране труда не определены.

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

Атрибуты качества ПО Доступность-1.Система должна быть доступна в рабочее время с 08.00 до 17:00 и во время проведения испытаний.

Приложение 2

Структура баз данных Приложение 3

Тестовые примеры

.ur