Курсовая работа (т): Автоматизации работы автобусного парка
Предусловия: Бухгалтер идентифицирован и аутентифицирован (имеет доступ к определенным ресурсам). Программа загружена.
Постусловия: Произведен расчет за электроэнергию. Занесение и сохранение соответствующей информации в базе данных системы.
Основной, успешный сценарий:
).Бухгалтер заносит все необходимые данные (количество маршрутов, пройденные ими расстояния) в систему.
).Система в конце каждого дня производит подсчет затраченной электроэнергии на каждый маршрут, соответственно учитывая расстояния маршрутов. Бухгалтер сохраняет в системе все данные в конце каждого дня.
).В конце каждой недели бухгалтер суммирует окончательный результат за оплату электроэнергии. Бухгалтер сохраняет в системе все данные в конце каждой недели.
).Бухгалтер представляет полученный отчет поставщику электроэнергии. Поставщик сверяет со своими расчетами, и при совпадении принимает оплату. Бухгалтер фиксирует в системе все проведенные расчеты и уплаты в «журнале оплаты за электричество».
Альтернативный сценарий 1:
).Не совпадение расчетов бухгалтера и поставщика.
. Бухгалтер заново вносит свои данные в систему. Система выдает новые данные об оплате.
. Бухгалтер представляет новый полученный отчет поставщику электроэнергии. Переход к п4).
Дополнительная спецификация.
Рассматривая дополнительную спецификацию, отметим, что она представляет собой документ, определяющий требования и ограничения, которые не охвачены моделями и документацией сценариев применения и концептуальных классов. Данные документ охватывает, главным образом, нефункциональные требования и ограничения, иными словами требования и ограничения не поведенческого характера, скорее всего ограничения и условия реализации. Данный документ составляется на основе описания требований. В качестве главной части проектирования любой информационной системы выступает определение основных требований, которые предъявляют к моделируемой системе.
Описание требования заказчика осуществляется на
основе 4-х категорий. Категории представим и опишем в таблице 1.4.
Таблица 1.4 Категории описания требований
|
Категория |
Описание |
|
F |
Функциональные требования, описывающие требуемую функциональность или прецеденты системы |
|
S |
Системные требования, такие как используемые платформы |
|
P |
Требования к представлению |
|
R |
Требования, определяющие риски, которым должно быть уделено основное внимание при разработке системы |
Функциональные требования категории F
выступают как некий перечень сервисов, который необходима выполнять система.
При этом, следует отметить, каким образом система реагирует на входные данные.
Описание функциональных требований показаны в таблице 1.5.
Таблица 1.5 Функциональные требования
|
Требование |
Тип |
Описание |
|
Аутентификация пользователя |
F |
Для работы в системе необходимо пройти аутентификацию |
|
Непротиворечивый ввод данных |
F |
Проверка типов данных на стадии ввода |
|
Отчеты по требованию |
F |
Отчеты, которые запрашивают вышестоящие органы |
В качестве второй категории в описании
требований выступает категория системных требований, - S.
Описание системных требований представим в таблице 1.6.
Таблица 1.6 Системные требования
|
Требование |
Тип |
Описание. |
|
Архитектура |
S |
Pentium IV 1GHz CPU |
|
Платформа |
S |
Windows XP |
|
СУБД |
S |
MySQL 5.1.40 |
|
Язык программирования |
S |
.NET Framework C# |
|
Информационно-логический язык |
S |
Язык структурированных запросов SQL Transact-SQL расширение языка SQL |
Требования к представителю (Р) относятся к третьей
категории. Они описывают формирование требований заказчика к интерфейсу
программного обеспечения. Описание требований к предоставлению показаны в
таблице 1.7.
Таблица 1.7 Требования к предоставлению
|
Требование |
Тип |
Описание. |
|
Интерфейс рабочего окна |
P |
Простая и строгая, не раздражающая глаза цветовая гамма |
|
Корректный ввод данных |
P |
Данные несоответствующих типов не принимаются, выдается предупреждение |
|
Простота интерфейса |
P |
Интуитивно понятный интерфейс |
К четвертой категории относится требования к
рискам (R). Эта категория
требований направлена на общую безопасность системы, а также она решает вопросы
сохранения непротиворечивости состояния баз данных, защиты от вторжений,
резервного копирования и восстановления. Описание требований к рискам показаны
в таблице 1.8.
Таблица 1.8 Требования к рискам
|
Требование |
Тип |
Описание |
|
Соответствие значений в таблицах внесенным данным |
R |
Поля в таблицах должны соответствовать типу введенных данных |
|
Построение отчетов |
R |
Полное соответствие содержимому в таблицах |
|
Сохранность и целостность данных |
R |
Система должна обеспечивать сохранность данных в случае непредвиденных сбоях |
Еще раз отметим, что спецификация требований представляет собой документ, в котором точно указаны все функции и возможности, которыми должно обладать программное обеспечение, а также там указаны все необходимые ограничения.
Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту.позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация SRS позволяет от определения предметной области проекта перейти к области решений, определив три модели требований, отображающие характеристики данных, процесса и поведения.
Данный документ должен содержать состав и наименование комплексов задач, требования по изменению организационной структуры, состав обеспечивающих подсистем. Спецификация требований к программному обеспечению представлена в Приложении 1.
Документ видение. Рассматривая данный документ, отметим, что данный документ представляет собой краткое описание сути будущего продукта. В данном документе кратко описано что это за продукт, каковы его цели и задачи, кто выступает в качестве его пользователей, а также каковы основные возможности будущей системы.
Заинтересованные лица:
Водитель: хочет осторожно и точно по расписанию производить маршрут.
Бухгалтер: хочет безошибочно и вовремя производить оплату с рабочими, точно отсчитывать прибыль и деньги в амортизационный фонд, в фонд налогов, за электроэнергию. Вовремя фиксировать необходимые данные в соответствующих журналах.
Депо: хочет, в случае необходимости производить ремонт - амортизацию транспорта.
Кондуктор: хочет зафиксировать в начале каждого маршрута количество билетов, выданных диспетчером, а также подсчитать их количество в конце маршрута.
Диспетчер: хочет правильно создавать путевые листы (расписание маршрутов), вовремя отправлять (принимать) транспорт на линию (с линии) маршрута. Следить за соответствием расписания и движения транспортов и регистрировать все отправления и прибытия транспортов в журнале регистрации.
Место системы.
Систему можно использовать на такой государственной организации, как городской электротранспорт.
Пользователи системы.
В качестве непосредственных пользователей системы могут выступать: водитель, диспетчер, бухгалтер и кондуктор городского электротранспорта.
Задачи и свойства системы.
Обеспечивать удобный интерфейс пользователя.
Реагировать на ошибки ввода - вывода данных.
Искать данные в системе по запросу.
Словарь терминов:
|
Термин |
Определение |
Синоним |
|
Товар |
Продаваемый продукт или услуга |
|
|
Авторизация платежа |
Подтверждение гарантии оплаты от внешней службы авторизации платежей |
|
|
Запрос на авторизацию платежа |
Набор элементов, отправляемых по электронной почте службе авторизации платежей, обычно в виде массива символов. К этим элементам относятся: идентификатор магазина, номер счета покупателя, сумма платежа и временная метка |
|
|
UPC |
Двенадцатизначный числовой код для идентификации продукта. Обычно он представляется в виде штрих-кода. Более подробная информации содержится по адресу http: \\www.uc-council.org |
Universal Product Code |
|
База данных |
это совокупность структурированных и взаимосвязанных данных и методов, обеспечивающих добавление выборку и отображение данных |
|
|
Концептуальная модель данных |
описанные знания о физических и логических объектах реального мира (люди, компоненты инфраструктуры, наряды на работу, договора, соглашения и т. д.), которыми необходимо управлять наиболее рациональным образом |
|
|
Логическая модель данных |
описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы. Строится на основе концептуальной модели данных. |
|
|
Интерфейс пользователя (UI) |
это часть программы, которая находится на виду у пользователя и призвана обеспечивать отображение данных, управление или диалог с пользователем. |
|
|
Графический интерфейс пользователя (ГИП), графический пользовательский интерфейс (ГПИ) |
разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений. |
|
|
C# |
это язык программирования, предназначенный для разработки самых разнообразных приложений, предназначенных для выполнения в среде .NET Framework. Язык C# прост, строго типизирован и объектно-ориентирован. |
|
. Модель предметной области
В данном разделе мы поговорим о модели предметной области, при этом отметим, что данная модель показывает основные классы понятий. Модель предметной области представляет собой визуальное представление концептуальных классов либо же объектов реального мира в терминах предметной области. Иными словами, данная модель это некая визуализация понятий предметной области, которая напоминает статическую модель сущностей предметной области.
При этом отметим список категорий концептуальных
классов. (см. таблица 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 - Диаграмма
концептуальных классов
Атрибуты классов
ItineraryIt-ry: text. Stop: intStop:
textbetween Stop: doubleA: doubleB: double: doublesale ticket: double: double:
double: double: doubleT-t: int: textA: doubleB: doubleDriver: text: double:
double: FIO: text: Phone Number_Register_Dispatch: textry: double_Tr-t:
doubleA: doubleB: double: text: int_number: int
3.
Модель
проектирования
В данном разделе нами будет рассмотрена модель проектирования. При этом отметим, что модель проектирования представляет собой некий набор диаграмм, которые описывают логику проектного решения. Модель проектирования включает в свой состав диаграмму последовательности, диаграмму кооперации, диаграмму программных классов и интерфейсов.
При этом, на основании нашего исследования, отметим следующее:
Прецедент: Распределение
транспорта по маршрутам.
Описание операции ОП 1 Таблица 3.1
|
Операция |
Transport_Itinerary |
|
Ссылки |
Распределение транспорта по маршрутам и занесение данных в журнал регистрации |
|
Предусловия |
Бухгалтер идентифицирован и аутентифицирован. |
|
Постусловия |
Транспорт распределен. Данные занесены в журнал. |
Рисунок 3.1 Прецедент:
Начисление заработной платы
Описание операции ОП 2 Таблица 3.2
|
Операция |
Receive_Profit |
|
Ссылки |
Подсчет прибыли. |
|
Предусловия |
Бухгалтер идентифицирован и аутентифицирован. |
|
Постусловия |
Прибыль подсчитана, данные занесены в систему. |
Рисунок 3.2
Таблица 3.3 Описание операции ОП 3
|
Операция |
Pay_Salary |
|
Ссылки |
Выделение средств оплаты услуг работникам |
|
Предусловия |
Бухгалтер идентифицирован и аутентифицирован. |
|
Постусловия |
Средства выделены, данные записаны в журнале системы. |
Рисунок 3.3 Прецедент: Оплата за электроэнергию
Таблица 3.4 Описание операции ОП 4
|
Операция |
Pay_Supplier |
|
Ссылки |
Выделение средств оплаты услуг поставщика энергии. |
|
Предусловия |
Бухгалтер идентифицирован и аутентифицирован |
|
Постусловия |
Средства выделены, данные записаны в журнале системы |