Файл: «Проектирование реализации операций бизнес-процесса «Взаиморасчеты с клиентами»» ..pdf

1. Прием, обработка и ввод первичной входящей информации (паспортные данные, реквизиты организаций и т.д.).
2. Формирование документов (договора и т.д.).

Графическое представление информационной модели отражено на рис. 2.4.

Рисунок 2.4 - Информационная модель системы взаиморасчеты с клиентами в ООО «Фитнес клаб»

2.2 Характеристика нормативно-справочной, входной и оперативной информации

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

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

Разработанная модель находится в 3-й нормальной форме, так как:

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

2.3 Характеристика результатной информации

В ходе деятельности разработанной системы взаиморасчеты с клиентами в ООО «Фитнес клаб» формируются следующие выходные документы:

• Отчеты;

2.4 Общие положения (дерево функций и сценарий диалога)

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

Взаимодействие с пользователем осуществляется посредством экранных форм. Дерево диалога (граф перехода экранных форм) приведено на рисунке 2.5.

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

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

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

Состав и классификация функций разрабатываемого программного продукта представлены в виде дерева функций (рис. 2.5).

Рисунок 2.6 – Дерево функций ИС

Сценарий диалога представлен на рисунке 2.6.

Рисунок 2.6 – Диалог с ИС

Обмен информацией между пользователем и компьютером (точнее, его программным обеспечением) по всем формальным признакам соответствует понятию “диалог”. При проектировании диалога, необходимо определить:

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

2.5 Характеристика базы данных

Инфологическая (концептуальная) модель — это формализованное описание предметной области, выполненное безотносительно к используемым в дальнейшем программным и техническим средствам.[3] Инфологическая модель должная быть динамической и позволять легкую корректировку. К основным требованиями, предъявляемым к инфологической модели, можно отнести следующие:

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

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

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

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

При анализе предметной области были выделены следующие наиболее важные объекты и их свойства.

Помещение (код помещения, название, вид занятий, этаж). Объект содержит информацию о помещениях, в которых проводятся занятия.

Тренер (код тренера, Ф.И.О., адрес, телефон, возраст). Объект содержит информацию о тренерах, работающих в спорткомплексе.

Группа (код группы, название, специализация). Объект содержит информацию обо всех группах, которые занимаются в спорткомплексе.

Посетитель (код посетителя, код группы, Ф.И.О.). Объект содержит информацию обо всех посетителях, которые подразделены на группы.

День недели (код дня, день недели). Объект хранит все дни недели, в которые работает спорткомплекс.

Время (код времени, время). Объект хранит информацию о времени начала и окончания занятий.

Для системы были выделены следующие сущности: «Помещение», «Тренер», «Группа», «Посетитель», «Расписание», «День и время», «День проведения занятий» и «Время проведения занятий». Рассмотрим наглядно взаимодействие этих сущностей. Для этого построим ERD-модель данных (Рисунок 2.7).

Рисунок 2.7 – Инфологическая схема (ER-модель)

Связи между сущностями:

Сущность «группа» связана (М:М) с «посетителями», один посетитель может находиться в нескольких группах.

Сущность «группа» связана (1:М) с «расписанием» значит для определенной группы может быть сформировано расписание с разными тренерами, помещениями и в разные дни недели и время.

Сущность «тренер» связана (1:М) с «расписанием» значит для определенного тренера может быть сформировано расписание с разными группами, помещениями, днями недели и временем.

Сущность «помещение» связана (1:М) с «расписанием» значит, в определенном помещении могут заниматься множество групп с различными тренерами, и в разные дни недели и время.

Сущности «день проведения занятий» и «время проведения занятий» связаны (1:M) c сущностью «день и время», каждый рабочий день недели содержит все промежутки времени начала и окончания занятий.

Сущность «день и время» связано (1:М) с «расписанием», расписание содержит разные дни недели и разное время занятий проводимых в спорткомплексе для всех подразделений.

Сущность «группа» связана (1:М) с сущностью «вид спортивного занятия», группа занимается определенным видом спорта.

Анализируя каждую сущность и связи между ними, создадим необходимые таблицы базы данных (Таблица 2.2).

Таблица 2.2

Таблицы базы данных

2.6 Структурная схема пакета (дерево вызова программных модулей)

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

• справочники
• документы
• отчеты
• обработки
• регистры.

Следовательно, структуру программы можно описать следующими основными блоками представленными на рисунке 2.8 .

Рисунок 2.8 - Блок-схема основных модулей программы

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

Описание программных модулей представлено в таблице 2.3.

Таблица 2.3

Описание программных модулей