Файл: Разработка информационной системы салонакрасоты на платформе 1С Предприятие.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.11.2023
Просмотров: 185
Скачиваний: 8
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
14
Рисунок 1.5 – IDEF0 диаграмма «КАК ДОЛЖНО БЫТЬ» декомпозиции бизнес-процесса «Оказание услуги».
Теперь стала доступна АИС, которая помогает осуществлять бизнес- процесс «Оказание услуг». Благодаря этому сотрудники тратят меньше времени на оформление документов, что позволит обслужить большее количество клиентов за аналогичное время.
Выводы по главе 1
В первой главе выпускной квалификационной работы было произведено описание и функциональное моделирование салона-красоты. Был произведен анализ деятельности салона-красоты, выявлены требования к реализации информационной системы. Была построена диаграмма IDEF0 «КАК ЕСТЬ», а затем, на основе требований, «КАК ДОЛЖНО БЫТЬ».
Результатом работы в 1 главе стали поставленные задачи на проектирование и разработку АИС . Теперь, чтобы реализовать поставленные задачи предстоит сделать логическое проектирование АИС.
15
ГЛАВА 2 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Выбор технологии логического моделирования
автоматизированной информационной системы
Для проектировании информационной системы необходимо описать автоматизируемые процессы, а уже из этого строится логическая модель проектируемой системы. Информационная система разрабатывается на основании логической модели, в которой будет воплощены метаданные разрабатываемой конфигурации.
При необходимости внесения изменений в проект используется механизм технических проектов. Изменения основываются на принятых требованиях и документируются c привязкой к изменяемым процессам, а также объектам логической и физической модели.
В соответствии с концепцией бизнес-моделирования формализация модели проектируемой системы необходима для уточнения основных выводов из ее концептуальной модели и для постановки задачи на разработку программного обеспечения.
В методологии бизнес-моделирования, при построении логической модели системы, предпочтение желательно отдавать методологиям объектно- ориентированного проектирования и анализа, использующим нотацию языка
UML (Unified Modeling Language).
Для логического моделирования будет применяться объектно- ориентированная нотация языка UML пакета MS Visio.
Для демонстрации требований, описанных в первой главе и предъявляемых к системе, используется диаграмма вариантов использования. В диаграмме вариантов использования продемонстрирована совокупность прецедентов и актеров, а также существующие отношения между ними. С помощью прецедентов моделируется поведение подсистемы или системы в целом.
16
Моделируя поведение элемента при помощи диаграммы вариантов использования, обеспечивается представление поведения информационной системы с высокой степенью детализации. Прецеденты делают возможным общение конечных пользователей и разработчиков на одном языке. Элементы, представленные в диаграмме прецедентов, могут быть сложными образованиями с большим количеством операций и составных частей.
Описание прецедентов определенного элемента, даст понимание конечным пользователям каким образом с ним обращаться.
2.2 Логическая модель автоматизированной информационной
системы и ее описание
У любой АИС должна быть логическая модель, необходимо отобразить все нюансы, с которыми может столкнуться данная система во время эксплуатации. Необходимо четко выстроить логику действия системы.
В качестве инструмента проектирования логической модели информационной системы салона красоты был выбран язык UML.
Язык UML является графическим языком. Данный стандарт применяется для создания абстрактной модели разрабатываемой системы, которую называют UML-моделью. Этот язык моделирования не относится к языкам программирования, но на основании разработанных моделей при помощи UML существует возможность генерации кода. Рассмотрим диаграммы, которыми впоследствии воспользуемся для создания логической модели.
Создание логической модели несет целью переход от концептуальной точки зрения «КАК ДОЛЖНО БЫТЬ» к диаграмме прецедентов. Диаграмма отражает функциональные возможности системы взглядом со стороны, выявляет их взаимосвязь, а также способствует выявлению структуры системы.
Для того, чтобы наглядно отобразить функциональное назначение системы, то есть то, что система будет делать в процессе своего функционирования, используется диаграмма вариантов использования. Данная диаграмма не предназначена для отображения проекта и не может описывать
17 внутреннее устройство системы. Диаграммы вариантов использования предназначены для упрощения взаимодействия с будущими пользователями системы, с клиентами, и особенно пригодятся для определения необходимых характеристик системы.
Другими словами, диаграммы вариантов использования говорят о том, что система должна делать, не указывая сами применяемые методы. Диаграмма вариантов использования разрабатывается для определения общих границ и контекста моделируемой предметной области на начальных этапах проектирования системы. Также данная диаграмма формулирует общие требования к функциональному поведению проектируемой системы. Данная диаграмма позволяет разработать первичную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. На диаграммах вариантов использования изображаются такие компоненты, как актеры и варианты использования.
Между компонентами существуют отношения: обобщение, включение, расширение. Актером называется любой объект, взаимодействующий с системой. Вариант использования – это спецификация функций, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемых системой при взаимодействии с актером.
Далее необходимо выполнить трансформацию структурно- функциональной модели «Оказания услуги» в UML-диаграмму вариантов использования (рисунок 2.1).
18
Рисунок 2.1 - Диаграмма вариантов использования процесса «Оказания услуг» после внедрения информационной системы
Рисунок 2.1 представляет собой диаграмму вариантов использования бизнес-процесса «Оказания услуг» и демонстрирует базовый функционал программного продукта. Одной из главных задач разрабатываемого продукта является введение данных о клиенте, дате и времени, а также позиции, которые выбрал клиент. Другой важной задачей является ведение базы данных, учитывающей тип и количество товара, информацию об оказании услуг. У сотрудника будет возможность планировать график оказания услуг, а также производить инвентаризацию имеющихся товаров с помощью системы, что повысит скорость обслуживания клиента.
Диаграмма деятельности поэтапно описывает все процессы. Здесь будут пошагово описаны все действия, которые совершат актеры. На этих диаграммах можно показать распараллеливание процесса на подпроцессы и слияние подпроцессов. Для обозначения этих действий используются жирные горизонтальные или вертикальные линии. На рисунке 2.2 был отображен процесс «Оказание услуг».
19
Рисунок 2.2 - Диаграмма деятельности процесса «Оказание услуг».
Ключевым условием выполнения этого процесса является наличие тех или иных товаров. Чтобы оказать услугу, необходимо наличие некоторые сопутствующих товаров, например для пирсинга потребуется выбрать серьгу, иглу и одноразовые перчатки, чтобы все было стерильно. Дорожки, используемые на данной диаграмме деятельности, символизируют роль пользователя или организационное подразделение, осуществляющее определенные действия в рамках данной деятельности.
С помощью диаграммы вариантов использования выявляются основные пользователи системы и задачи, которые данная система должна решать, а с
20 помощью диаграммы деятельности появляется возможность описать последовательность действий для каждого прецедента, необходимую для достижения поставленной цели.
На основе построенных выше диаграмм была разработана диаграмма классов, приведенная на рисунке 2.3, которая отображает внутреннее устройство приложения.
Рисунок 2.3 – Диаграмма классов информационной системы.
Также потребуется продумать логику работы документов. Например, как оформить заказ, потребуется ли для этого сначала добавить клиента, а уже потом начать формировать услугу? Для этого нам поможет диаграмма в нотации EPC. Данная диаграмма состоит из следующих элементов:
21
Событие – состояние, являющееся существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов.
Функция – действие или набор действий, выполняемых над исходным объектом, например, документом с целью получения заданного результата.
Связи – соединение элементов диаграммы процесса EPC между собой.
Одно событие может инициировать выполнение одновременно нескольких бизнес-функций, и, наоборот, в результате выполнения функции могут наступить нескольких событий. Такие ветвления и циклы обработки отображаются на диаграмме EPC с помощью операторов AND («И»),
OR(«ИЛИ»), XOR («Исключающее ИЛИ»).
Рисунок 2.4 - Диаграмма нотации EPC процесса «Добавления клиента»
По логике вещей, чтобы выполнить документ «Оказание Услуг», необходимо сначала добавить клиента в справочник «Клиент», создать склад, с
22 которого будем брать товар, выбрать сотрудника, который будет обслуживать клиента, а самое главное заранее составить список товаров и услуг, доступных для оказания услуги.
Система в любой момент должна иметь возможность вносить новые данные, постоянно вести товарооборот, а также фиксировать все совершенные экономические операции.
2.3 Разработка спецификации интерфейса
На главной странице должны быть расположены подсистемы:
«Бухгалтерия», «Учет товаров», «Оказание услуг», «Бухгалтерия», «Расчет зарплаты» и «Предприятие».
В каждой из этих подсистем должны располагаться соответствующие справочники, документы и отчеты.
1. Учет товаров:
Номенклатура;
Приходная накладная;
Склады;
Остатки товаров;
1.1 Создание позиций для:
Номенклатуру;
Склад;
Приходная накладная;
1.2 Отчеты:
Учет товаров;
1.3 Сервис:
Форма констант
2. Оказание услуг:
Клиенты;
Номенклатура;
23
Оказание услуг;
Сотрудники;
2.1 Создание позиций для:
Оказание услуги;
Клиент;
Номенклатура;
2.2 Сервис:
Форма констант;
Оформление продажи;
3.Бухгалтерия:
Должности;
Начисление зарплат;
План расчета;
3.1 Еще:
Приходная накладная;
Физические лица;
Остатки товаров;
4. Расчет зарплаты:
Должности;
Сотрудники;
4.1 Создание позиций для:
Сотрудник;
5. Предприятие:
Должности;
Приходные накладные;
Склады;
Интерфейс должен быть понятен и удобен для финального пользователя, все необходимые функции должны быть разбиты по подсистемам.
24
2.4 Проектирование базы данных автоматизированной
информационной системы
Так как наш основной бизнес-процесс – это «Оказание услуги», то ключевым элементом базы данных должен выступить объект «Услуга». Именно в ней собираются все данные, которые имеются на данном предприятии:
Услуга;
Клиент;
Номенклатура;
Тип услуги;
Чек;
Сотрудник;
Должность;
Склад.
Рисунок 2.5 – Логическая модель данных АИС
Как видим из рисунка 2.5, во время оказания услуги, не заполняются никакие данные, кроме даты
(стоимость должна рассчитываться автоматически). Все данные подставляются по коду, это позволяет сэкономить
25 время, что повысит эффективность бизнес-процесса. Стоит отметить, что благодаря разработанной логики, а также особенности платформы
«1С:Предприятия», можно вносить новые данные в любой момент деятельности бизнес-процессов.
Выводы по главе 2
Во второй главе выпускной квалификационной работы, с помощью диаграмм UML, была спроектирована логическая модель информационной системы, были установлены основные правила поведения в различных ситуациях, которые могут произойти, если данные не полные, также была спроектирована база данных и интерфейс.
Результатом деятельности второй главы стала спроектированная логическая система, на основе которой уже можно разрабатывать физическую модель. Была спроектирована логика процесса «Оказание услуг», где было учтено то, что клиент может не быть внесен в базу данных, на момент формирования процесса.
Были использованы такие диаграммы как: диаграмма вариантов использования; диаграмма деятельности; диаграмма классов; диаграмма нотации EPC.
26
ГЛАВА 3 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
3.1 Выбор архитектуры автоматизированной информационной
системы
На основе сформулированных требований, а также учитывая специфику предметной области, была выбрана платформа «1С:Предприятие 8.3»
Гибкость данной платформы позволяет использовать программы, которые уже встроены в платформу, для автоматизации учета и управления на торговых предприятиях, в бюджетных и финансовых организациях, сферы обслуживания и т.д.
Система программ «1С: Предприятие 8.х» обеспечивает:
● поддержку оперативного управления предприятием;
● автоматизацию организационной и хозяйственной деятельности;
● управление учетом, построения аналитической отчетности, поддержки многовалютного учета;
● создание многоязычных прикладных решений;
● удобный и настраиваемый интерфейс;
● механизм генерации отчетов любой сложности.
Встроенные инструменты формирования отчетов и печатных форм обеспечивают широкие возможности оформления и интерактивной работы:
● возможность формирования иерархических, многомерных и кросс- отчетов;
● произвольная настройка и получение любых аналитических отчетов;
● группировки и расшифровки в отчетах, детализация и агрегирование информации;
● сводные таблицы для анализа многомерных данных, динамическое изменение структуры отчета;