Добавлен: 30.06.2023
Просмотров: 331
Скачиваний: 5
СОДЕРЖАНИЕ
1 Предметная область автоматизации
1.1 Документы предметной области, содержащие информацию, необходимую для решения задачи
1.2 Описание предметной области и функции решаемой задачи
1.2.2 Выводы по автоматизации и реорганизации
1.2.3 Описание расширенной модели TO-BE, полученной после проектирования
2.1 Организационно-экономическая сущность задачи
2.2 Описание выходной информации
2.3 Описание входной информации
3 Информационное обеспечение задачи
3.1 Информационный анализ предметной области и выделение информационных объектов задачи
3.2 Определение логической структуры реляционной базы данных (ERD-модель)
4.1 Структурная схема программы
5 Детальные алгоритмы реализации отдельных модулей задачи
7 Технология решения задачи (функционально-технологические схемы)
- Фильмы;
- Сеансы;
- Билеты.
В системе за счет использования запросов сформированы документы:
- Список сеансов;
- Список ID билетов;
- Статистика.
3 Информационное обеспечение задачи
3.1 Информационный анализ предметной области и выделение информационных объектов задачи
Программное обеспечение используется для обеспечения продаж билетов кинотеатра. Продажа билетов осуществляется в отдельном интерфейсе.
В зависимости от статуса билета на текущий момент система может выдавать отчеты о трех состояниях билета – на продажу, проданном и возвращенном.
Взаимодействие информационных объектов показано на рисунке.
Рисунок 5 – Взаимодействие объектов
3.2 Определение логической структуры реляционной базы данных (ERD-модель)
Ниже представлена ER диаграмма базы данных информационной системы.
ER диаграмма представляет собой набор таблиц базы данных информационной системы, включающих связи по внешним ключам.
Рисунок 6 – ER диаграмма
Таблица 1. -Описание таблиц базы данных
Наименование таблицы |
Поле |
Тип |
Первичный ключ |
Внешний ключ |
Расписание |
RaspID |
Number(10) |
Да |
Нет |
Day |
Text(10) |
Нет |
Нет |
|
Time1 |
Date |
Нет |
Нет |
|
Time2 |
Date |
Нет |
Нет |
|
Time3 |
Date |
Нет |
Нет |
|
Time4 |
Date |
Нет |
Нет |
|
Time5 |
Date |
Нет |
Нет |
|
Tickets |
id |
Number(10) |
Да |
Нет |
TDate |
Long Integer |
Нет |
Нет |
|
TID |
Long Integer |
Нет |
Нет |
|
TCost |
Long Integer |
Нет |
Нет |
|
TPlace |
AutoNumber |
Нет |
Нет |
|
TTime |
AutoNumber |
Нет |
Нет |
|
Tablica1 |
FilmID |
Number(10) |
Да |
Нет |
Title |
Long Integer |
Нет |
Нет |
|
Description |
Long Integer |
Нет |
Нет |
|
SCost |
Number(10) |
Да |
Нет |
|
Rating |
Long Integer |
Нет |
Нет |
|
Gantre |
Long Integer |
Нет |
Нет |
Подробно рассмотрим программную архитектуру системы.
4 Архитектура системы
4.1 Структурная схема программы
Рассмотрим подробно работу каждого модуля программы информационной системы. Все программные модули перечислены в таблице.
Таблица 2 - Описание функций модулей
№ п/п |
Наименование модуля |
Функции модуля |
---|---|---|
Модуль Unit5 |
Описывает выбор фильма |
|
Модуль Unit4 |
Описывает процедуру выбора основных форм |
|
Модуль Unit3 |
Связывает интерфейс с таблицами базы данных и описывает основные программные формы |
Программная часть модулей реализована средствами языка Delphi, программная оболочка которого позволяет связывать их непосредственно с таблицами базы данных.
5 Детальные алгоритмы реализации отдельных модулей задачи
Рассмотрим алгоритмы работы основных модулей программы.
Рисунок 7. – Основной программный модуль
Модуль позволяет пользователю выбрать дату и сеанс, отследить покупку билета и его возврат, редактировать статистику на определенную дату.
При возврате билетов появляется возможность выбрать не только фильм, но и сеанс.
Рисунок 8.- Функции возврата билетов
Рассмотрим контрольный пример реализации проекта и его описание.
6 Интерфейс системы
В основном окне программы производится выбор даты похода в кинотеатр, фильма и сеанса и указывается количество свободных мест.
Рисунок 9. - Окно просмотра сеансов
После выбора сеанса происходит заказ билета.
Рисунок 10.- Заказ билета
После выбора мест пользователь производит их оплату. Информация по проведенной оплате выводится после покупки билета.
Рисунок 11. – Покупка билета
Если нужно возвратить билет используется отдельный интерфейс, который позволяет выбрать билет из списка и проверить его перед возвратом.
Рисунок 12. – Возврат билета
Кнопка «Статистика» выводит возможную статистику по продажам билетов и их возвратам с учетом периода продаж
Рисунок 13. - Статистика
Основной листинг программных модулей показан в Приложении.
7 Технология решения задачи (функционально-технологические схемы)
Разработка сложных программных комплексов вызывает необходимость решения ряда организационных, технологических и технических проблем, связанных со значительной трудоемкостью разработки программ и сложностью выявления в них ошибок. Решение этих проблем возможно при внедрении любой технологии программирования, которая позволит повысить производительность труда программистов и надежность программ. Кроме того, внедряемая технология должна упростить планирование работ и организацию взаимодействия всех членов коллектива, позволить четко контролировать сроки выполнения каждого этапа разработки, оперативно доводить до исполнителей все изменения в общих концепциях на создаваемое программное изделие и изменения в соглашениях о связях между программой и внешней средой или между отдельными структурными элементами программы. Технология должна обеспечить простоту и однозначность прочтения всей документации.
Сокращение сроков и снижение трудоемкости внедрения программного изделия зависят от его надежности. Поэтому технология должна предусматривать организацию процессов верификации и тестирования алгоритмов и программ на стадии разработки, также подходы к отладке и испытаниям программы. Технология должна обеспечивать возможность достаточно простой модификации программ при их эксплуатации, что необходимо для устранения обнаруженных ошибок или для изменения функций программы.
Технология разработки сложных программных комплексов требует разбиения программного изделия на отдельные модули. При этом часто модули создаются независимо друг от друга разными программистами. Для объединения модулей в программный комплекс необходимо разработать правила вызова модулей и правила передачи параметров между отдельными модулями. Эти правила образуют внутри- программный интерфейс.
Внутрипрограммный интерфейс должен разрабатываться на начальном этапе проектирования программы. Разработка его включает:
- анализ обрабатываемой информации и выбор логической организации данных;
- выбор абстрактных структур данных для представления информации в соответствии с используемым языком программирования равной логической организацией данных;
- выбор физической организации данных;
- выбор структуры и способов взаимодействия отдельных программных модулей.
Разработка состава сложного программного изделия является одним из основных этапов создания программы, на котором в составе программы необходимо выделить отдельные модули, определить их функции, порядок вызова, правил взаимодействия и взаимоподчиненности. Разбиение программы на модули следует выполнять с учетом сложившегося представления об основных свойствах модулей :
Модуль - независимая программа, которая может вызываться операционной системой или другим программным модулем. Ссылки на модуль выполняются по имени модуля.
Модуль должен возвращать управление тому модулю, который его вызвал.
Модуль должен иметь один вход и один выход. Единственность входа гарантирует замкнутость модуля, однозначность его вызова и существенно облегчает отладку и сопровождение программы.
Модуль должен иметь ограниченные размеры. Это требование определяется тем, что каждый модуль организует отдельную, сравнительно небольшую функцию. Кроме того, текст модуля должен быть обозримым для облегчения его понимания и сопровождения.
Работа модуля не должна зависеть от его предыдущих вызовов.
После того, как определена структура программы и основные типы передаваемых данных, устанавливаются соглашения о связях между модулями. Соглашения включают в себя правила вызова отдельных модулей, правила передачи параметров и правила связи разрабатываемого программного изделия с операционной системой.
Правильный выбор функций и последующее распределение их между модулями с учетом логических связей является основной задачей при проектировании сложных программ.
Наиболее широко распространенным подходом к проектированию является нисходящее программирование.
Этот подход интуитивно привлекателен, за последние несколько лет он подвергался неоднократному обсуждению в литературе. Нисходящее проектирование известно и под другими названиями, например "конструктивное программирование", "программирование пошаговым совершенствованием" и "иерархическое проектирование".
Нисходящее программирование основывается на последовательной декомпозиции решаемой задачи на некоторые абстрактные функции с последующим уточнением каждой из них. Таким образом, для сложной программы получается иерархическая система программных модулей.
На каждом шаге производится последовательное уточнение функций, реализуемых модулями.
Эта детализация выполняется до тех пор, пока не будет достигнуто элементарное представление операции при реализации каждой из функций.
Нисходящее программирование позволяет создавать достаточно сложные программы.
При этом требования к квалификации программистов, реализующих отдельные модули, могут быть снижены.
Схемы технологического процесса сбора, передачи, обработки и выдачи информации
В данном разделе представлены функционально-технологические схемы решения задачи.
В первую очередь рассмотрим задачу ведения справочников, назовем ее А1. Для ее реализации менеджер по ведению каталогов сортирует данные, а затем вводит данные в соответствующие таблицы. Задача ввода данных может быть разбита на несколько этапов. Функционально-технологическая схема решения задачи А1 приведена на рисунке 14.
Рисунок 14. - Функционально-технологическая схема задачи А1 «Ведение справочников»
Для каждого выделенного модуля разработана функционально-технологическая схема и детальный алгоритм ее кодирования. Блок-схема задачи А1 приведена на рисунке 14, а функционально-технологические схемы всех модулей задачи А1 – на рисунке 15.
Рисунок 15. - Схема решения задачи А1 «Ведение справочников»
Рисунок 16. - Функционально-технологические схемы модулей задачи А1
Руководство по запуску и работе с программной появляется при начале работы с ней в основном программном окне.
Рисунок 17 – Руководство пользователя
Заключение
В процессе работы над программным продуктом автором были выявлены и решены проблемы доступа из основного интерфейса к дополнительным меню и формам программы путем использования оригинального дизайна интерфейса и его эргономичного решения.