Файл: Проектирование реализации операции бизнес – процесса «Учет предоставления услуг салоном красоты».pdf
Добавлен: 19.06.2023
Просмотров: 94
Скачиваний: 2
СОДЕРЖАНИЕ
Информационная модель и ее описание
Характеристика нормативно-справочной, входной и оперативной информации
Характеристика результатной информации
Общие положения (дерево функций и сценарий диалога)
Описание логической модели данных
Структурная схема пакета (дерево вызова программных модулей)
Продолжение таблицы 1.1
отличается исключительной гибкостью по отношению к потребностям разработчика |
языка |
пользователям свободно менять его части |
|
Универсальность |
Код РНР очень похож на тот, который встречается в типичных программах на С или Pascal. Это заметно снижает начальные усилия при изучении РНР |
системных сервисов |
С его помощью можно одинаково изящно реализовать как то, что традиционно делается с помощью интерпретатора Kornshell, так и то, что пишется обычно на C |
Открытый исходный код |
Да |
Да |
Да |
В результате сравнительного анализа, для разработки системы был сделан выбор в пользу использования PHP, так как данный язык предоставляет программисту средства для быстрого и эффективного решения поставленных задач, одно из самых сильных преимуществ PHP перед другими языками программирования, используемыми для разработки web-приложений, – поддержка БД самых разных типов, а также PHP является лучшим серверным языком программирования для создания динамических веб-страниц.
PHP относится к языкам программирования, сценарии на которых исполняются на стороне сервера, поэтому для выполнения сценариев на стороне клиента был выбран язык JavaScript. Для определения содержимого web-страниц был выбран язык разметки – HTML5, который является самой последней и самой мощной версией стандарта HTML. Для определения внешнего вида web-страниц будет использоваться язык CSS3.
Для малых и средних предприятий требования к СУБД не являются слишком завышенными, как для крупных корпораций, которые останавливают свой выбор на продуктах ведущих фирм-производителей (Microsoft SQL, Informix, DB2, Sybase, Adabas) – данные СУБД обладают неограниченными возможностями масштабирования. А также при выборе системы – стоимость играет не последнюю роль, да и возможность держать людей в штате для обслуживания данной СУБД весьма ограничена.
Таким образом, для разработки системы был сделан выбор в пользу СУБД MySQL. Выбор в пользу MySQL был сделан в связи с тем, что корпорация Oracle ориентирует свой продукт на нужды малого и среднего бизнеса, декларируя следующие его возможности:
- высокая скорость работы;
- многопользовательская система;
- простая и эффективная система безопасности;
- легко работает с большими объемами данных и легко масштабируется;
- поддерживает большое количество серверных платформ;
- распространяется совершенно бесплатно, используя лицензию GNU.
Проектируемая АИС должна удовлетворять следующим требованиям к защите информации:
- защита информации в АИС от случайных угроз должна осуществляться путем копирования информации каждые сутки;
- доступ к базам данных должен быть защищен паролями, устанавливаемыми администратором баз данных для конкретных пользователей, что обеспечит защиту передаваемой и хранимой информации от изменения, копирования и уничтожения;
- не должны допускаться неавторизованные попытки доступа к файлам системы и базам данных;
- на основании закона N152-ФЗ «О персональных данных» каждая организация, владеющая персональными данными своих сотрудников, клиентов, партнеров и так далее, обязана обеспечивать конфиденциальность всей этой информации. В случае нарушения положений закона компания может лишиться лицензии и подвергнуться судебному преследованию со стороны граждан, чьи приватные записи были скомпрометированы. Поэтому необходимо обеспечить разграничение прав доступа, а также защиту от несанкционированного доступа. Кроме этого, должно быть подписано соглашение работником учреждения о том, что он не возражает, чтобы его персональные данные обрабатывались в этой системе.
К проектируемой АС были выдвинуты следующие требования по расширяемости:
- система должна быть расширяема по модулям и функциям;
- система должна быть расширяема по пользователям.
Также АС должна предусматривать добавление новых компонент по мере их разработки минимальными усилиями.
Надежное (устойчивое) функционирование АС должно быть обеспечено выполнением:
- организацией бесперебойного питания технических средств;
- использованием лицензионного программного обеспечения;
- регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов;
- регулярным созданием резервных копий данных.
Интерфейс системы должен обладать следующими свойствами:
- единые формы ввода и редактирования информации;
- следование установленным стандартам разработки интерфейса;
- открытие диалоговых форм по центру экрана;
- одновременная работа только с одной формой;
- использование не броских цветов, не более трёх на одном экране;
- для выделения информации на экране используется стандартный шрифт, 12 размер, выделение жирным, для обычной информации – стандартные настройки шрифтов.
ПРОЕКТНАЯ ЧАСТЬ
Информационная модель и ее описание
Информационная модель системы представлена на рисунке 2.1 в виде схемы данных, которая представляет собой структурное представление движения информационных потоков с момента поступления входной информации к менеджеру до момента получения отчета.
Рисунок 2.1. Информационная модель системы
Характеристика нормативно-справочной, входной и оперативной информации
Для удобства ввода и хранения входных данных в разрабатываемой системе используется следующая нормативно-справочная информация:
- услуги;
- материалы;
- сотрудники;
- клиенты.
При машинной реализации задачи автоматизации работы менеджера салона красоты с заявками для формирования входного оперативного файла используются данные из первичного документа «Визиты».
Входной документ «Визиты» содержит следующие реквизиты:
- код визита;
- дата и время;
- код клиента;
- код сотрудника;
- сумма с учетом скидки;
- комментарий;
- статус.
Макет ввода данных представлен на рисунке 2.2.
Рисунок 2.2. Макет ввода данных
Структура файлов базы данных приведена в разделе 2.5 данной курсовой работы.
В результате обработки всех информационных файлов, используемых при решении задачи работы с заявками, пользователь получает три выходных документов (дневной отчет по выручке салона, а также по затраченным материалам), которые выводятся на экран дисплея, в файловую систему, а также на принтер.
Характеристика результатной информации
В данном разделе описан документ, поучаемый в результате выполнения всех запросов данной задачи и произошедших событий. Результативным документом (в электронной форме) является «Дневная выручка салона и затраченные материалы».
Выходной документ «Дневная выручка салона и затраченные материалы» содержит следующие данные:
- сумма выручки с каждого заказа;
- список затраченных материалов.
Данный выходной документ формируется всякий раз, когда менеджер делает запрос к БД из системы. После чего он его экспортирует в файловую систему, а также выводит его на печать.
Общие положения (дерево функций и сценарий диалога)
В данном разделе приведена иерархия функций управления и обработки данных, которые призваны автоматизировать разрабатываемую ИС.
Можно выделить и детализировать два подмножества функций: реализующих служебные функции (например, проверка пароля) и реализующих основные функции управления и обработки данных: ввода первичной информации, обработки, ведения справочников, ответов на запросы и др.
Дерево функций представлено на рисунке 2.3.
Рисунок 2.3. Дерево функций
В связи с тем, что при решении задачи используется технология обработки информации в режиме диалога, взаимодействие пользователя с системой можно представить в виде схемы диалога (рисунок 2.4).
С помощью модуля меню «Главное меню» осуществляется доступ к пяти основным пунктам меню:
- Клиенты;
- Визиты;
- Дневной отчет;
- Сотрудники;
- Услуги;
- Материалы;
- Выход из системы.
Рисунок 2.4. Схема диалога
Характеристика базы данных
Описание логической модели данных
В качестве модели данных для проектируемой системы была выбрана реляционная модель. Исходя из выбранной модели данных, была спроектирована с помощью CASE – средства ERwin схема логической (диаграмма ERD – модель сущность-связь) модели данных, представленная на рисунке 2.5.
Рисунок 2.5. Логическая модель данных
Спроектированная логическая модель данных имеет следующие сущности, представленные в таблицах 2.1 – 2.8:
Таблица 2.1
Описание атрибутов сущности «Клиенты»
Название атрибута |
Описание атрибута |
Код клиента |
Уникальный идентификатор клиента |
Фамилия |
ФИО клиента |
Имя |
|
Отчество |
|
Номер телефона |
Контактные данные |
Электронная почта |
|
Дата рождения |
Дата рождения |
Скидка |
Процент скидки |
Таблица 2.2
Описание атрибутов сущности «Услуги»
Название атрибута |
Описание атрибута |
Код услуги |
Уникальный идентификатор услуги |
Наименование |
Наименование услуги |
Продолжительность |
Продолжительность услуги |
Стоимость |
Стоимость услуги |
Номер зала |
Номер зала |
Таблица 2.3
Описание атрибутов сущности «Материалы»
Название атрибута |
Описание атрибута |
Код материала |
Уникальный идентификатор материала |
Наименование |
Наименование материала |
Единица измерения |
Единица измерения |
Цена материала |
Цена материала |
Объем |
Объем |
Таблица 2.4
Описание атрибутов сущности «Сотрудники»
Название атрибута |
Описание атрибута |
Код сотрудника |
Уникальный идентификатор сотрудника |
Фамилия |
ФИО сотрудника |
Имя |
|
Отчество |
|
Номер телефона |
Контактные данные |
Электронная почта |
|
Оклад |
Оклад |
Таблица 2.5
Описание атрибутов сущности «Оказываемые услуги»
Название атрибута |
Описание атрибута |
Код |
Уникальный идентификатор оказываемой услуги |
Код сотрудника |
Уникальный идентификатор сотрудника |
Код услуги |
Уникальный идентификатор услуги |
Таблица 2.6
Описание атрибутов сущности «Визиты»