Добавлен: 11.01.2024
Просмотров: 133
Скачиваний: 4
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Рисунок 1.2 – DFD-декомпозиция бизнес-процесса управления заказами ООО «Честер» (г.Тольятти) «КАК ЕСТЬ» (1-й уровень)
Рисунок 1.3 – DFD-декомпозиция процесса «Формирование заказа» «КАК ЕСТЬ» (2-й уровень)
Данная модель является основой для анализа и дальнейшего совершенствования бизнес-процесса управления заказами клиентов ресторана.
1.3.2 Анализ недостатков существующего бизнес-процесса и рекомендации по его усовершенствованию с помощью интернет-
технологий
Анализ модели «КАК ЕСТЬ» показал, что существующий бизнес-процесс малоэффективен и имеет следующие недостатки:
− невысокая эффективность маркетинга ресторана, обусловленная отсутствием собственного Web-представительства;
− отсутствие возможности онлайнового режима ввода заказов клиентами.
С учетом вышеизложенного принято решение улучшить бизнес-процесс
путем разработки и внедрения Web-представительства ООО «Честер», обеспечивающего возможность онлайнового режима ввода заказов клиентами.
1.3.3 Разработка модели «КАК ДОЛЖНО БЫТЬ» бизнес-процесса управления заказами ООО «Честер»
На рисунках 1.4-1.6 представлена модель «КАК ДОЛЖНО БЫТЬ» бизнес-процесса управления заказами ОО «Честер» (разработанная с помощью методологий IDEF0 и DFD.
Рисунок 1.4 – Контекстная диаграмма бизнес-процессов управления заказами
ООО «Честер» «КАК ДОЛЖНО БЫТЬ» (0-й уровень)
На представленной диаграмме изображены следующие элементы: − входные данные: Онлайн-заказ;
− выходные данные: Чек, Отметка о выполнении заказа;
− управляющие воздействия: Закон РФ «О защите прав потребителей», Инструкция по управлению заказами клиентов;
− исполнители: Клиент, Работник ресторана, Web-представительство.
Рисунок 1.5 – DFD-диаграмма бизнес-процесса управления заказами ООО «Честер» «КАК ДОЛЖНО БЫТЬ» (1-й уровень)
Новые и измененные элементы выделены красным цветом.
Рисунок 1.6 – DFD-декомпозиция процесса «Формирование заказа» «КАК
ДОЛЖНО БЫТЬ» (2-й уровень)
Таким образом, усовершенствование исследуемого бизнес-процесса достигается путем разработки и внедрения Web-представительства, отвечающего требованиям заказчика.
Глава 2 Разработка web-представительства ООО
«Честер».
2.1 Проектирование базы данных Web-представительства Логическое моделирование предназначено для создания объектной
модели программной архитектуры системы и логической модели данных.
Для обоснования и постановки задачи на разработку логической модели данных Web-представительства используется методология объектно-ориентированного проектирования и анализа, основанная на языке UML [12].
В концепции UML для описания системы с различных точек зрения используются три типа моделей: функциональная, модели классов и модель взаимодействий.
Полное описание системы требует наличия всех трех моделей.
Каждая модель применяется на всех этапах проектирования и строится с помощью специальных диаграмм языка UML.
2.1.1 Диаграмма вариантов использования бизнес-процесса
управления заказами клиентов
На первом этапе строим диаграмму вариантов использования, которая представлена на рисунке 2.1.
Диаграммы вариантов использования (use case diagram) применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к проектируемой системе при ее проектировании и разработке. Диаграмма вариантов использования строится на основе DFD-декомпозиции бизнес-процесса управления заказами «КАК ДОЛЖНО БЫТЬ», представленной на рисунке 1.5.
Рисунок 2.1 – Диаграмма вариантов использования бизнес-процесса
управления заказами клиентов ООО «Честер» «КАК ДОЛЖНО БЫТЬ»
Диаграмма вариантов использования описывает функциональный аспект рассматриваемой информационной системы «КАК ДОЛЖНО БЫТЬ», предоставляя дополнительную информацию об отношениях между различными вариантами использования и внешними пользователями-актерами.
2.1.2 Диаграмма классов Web-представительства Диаграмма классов описывает статическую структуру объектов системы
и их отношения. Эта модель определяет контекст разработки программы, то есть предметную область. Модель классов изображается на диаграммах классов. Диаграмма классов – это граф, вершинами которого являются классы, а ребрами – их отношения.
Построение диаграммы классов системы производится следующим образом:
25
в описании классов выделяются кандидаты в классы
– существительные, которые потенциально могут соответствовать классам (при этом следует помнить, что существительные могут относиться к объектам, ассоциациям или атрибутам классов);
анализируются роли кандидатов в системе. Каждый класс должен выполнять некоторые действия и взаимодействовать с другими классами. Он должен иметь также уникальное имя, отражающее характер абстракции, представляемой данным классом.
На рисунке 2.2 изображена диаграмма классов Web-представительства.
Рисунок 2.2 – Диаграмма классов Web-представительства
Спецификация классов:
Клиент – класс объектов-пользователей Web-представительства, выполняющих ввод онлайновых заказов;
Работник ресторана – класс объектов-пользователей Web-представительства, формирующих чеки и обслуживающих заказы клиентов;
Заказ – класс объектов-документов; Чек – класс объектов-документов.
Представленная диаграмма предназначена для разработки объектной
модели приложения Web-представительства.
2.1.3 Диаграмма последовательности бизнес-процесса управления
заказами
Диаграмма последовательности (sequence diagram) отображает динамический аспект системы, представлена на рисунке 2.3.
В рамках динамического аспекта реализуется ситуационный подход, позволяющий решить следующие задачи:
определение способов выполнения процесса в зависимости от конкретной ситуации. Выбор способа реализации (сценария) определяется с привлечением того или иного ответственного исполнителя (актера);
определение взаимодействия организационного, функционального и элементного аспектов;
определяется документооборот (обмен сообщениями) между взаимодействующими исполнителями.
Рисунок 2.3 – Диаграмма последовательности бизнес-процесса управления заказами клиентов ресторана
В случайный момент времени объект Клиент отправляет объекту Работник ресторана сообщение «Открыть заказ».
Объект Работник ресторана формирует чек и отправляет его объекту
Клиент по электронной почте с сообщением «Оплатить чек».
Объект Клиент оплачивает чек и отправляет объекту Работник ресторана подтверждение оплаты чека.
Объект Работник ресторана сообщает объекту Клиент о подтверждении заказа.
2.2 Разработка логической модели данных Web-сайта
Логическая модель данных является начальным прототипом будущей
базы данных.
Логическая модель данных – описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы [8].
Логическая модель данных строится в терминах информационных единиц, но без привязки к конкретной СУБД.
Логическая модель данных строится на основе диаграммы классов, представленной на рисунке 2.2, которая трансформируется в ER-модель («сущность-связь»).
Затем в модель добавляются новые сущности, необходимые для обеспечения необходимого уровня нормализации данных.
На рисунке 2.4 изображена логическая модель данных Web-представительства, разработанная в методологии IDEF1X.
Как следует из рисунка, в процессе разработки выделены следующие основные сущности:
− Клиент; − Заказ;
− Работник ресторана; − Чек
Рисунок 2.4 – Логическая модель данных Web-представительства
Дополнительные сущности Учетная запись, Статус, Меню и Бригада
введены для приведения модели к уровню нормальной формы Бойса-Кодда. Между основными сущностями логической модели установлены
следующие связи:
− Клиент может сделать несколько Заказов («один ко многим»);
− Работник ресторана может обслужить несколько Заказов («один ко многим»);
− По каждому заказу может быть сформирован только один Чек («один к одному»).
Все связи между основными сущностями неидентифицирующие. Представленная логическая модель данных является концептуальной
моделью данных Web-представительства и будет использована в качестве основы при проектировании реляционной модели базы данных системы на стадии физического моделирования данных.
2. 3. Выбор архитектуры Web-представительства
Информационные системы, разрабатываемые с помощью Web- технологий, реализуются в архитектуре «клиент-сервер» [4].
Архитектура «клиент-сервер» может быть представлена в следующих вариантах:
1. Традиционная двухзвенная архитектура «клиент - сервер».
Первое звено – клиентские компьютеры с прикладными программами, с помощью которых пользователи обращаются по сети к базе данных.
Второе звено – сервер баз данных, также участвующий в обработке данных.
Благодаря двухзвенной архитектуре снижается нагрузка на информационную сеть, поскольку передаются только запросы и ответы на них.
Преимущества:
распределение функций вычислительной системы между несколькими независимыми компьютерами в сети, это позволяет упростить обслуживание вычислительной системы, в частности, замена, ремонт, модернизация или перемещение сервера, не затрагивают клиентов;
все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов;
на сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа.
Недостатки:
ограниченность применения для Web-приложений; высокая стоимость оборудования клиентов.
2. Трехзвенная архитектура «клиент - сервер».
Первое звено – клиентская программа. Клиент посылает запросы на выполнение нужных действий. Вся логика системы реализуется на других уровнях, поэтому требования к клиентской машине минимальные. Такие
клиентские программы называют тонкими клиентами. В качестве базового
программного обеспечения используются Web-браузеры- IE, Mozilla и другие. Второе звено – сервер приложений – программное обеспечение
промежуточного уровня. Синхронизирует работу компонентов всей системы и организует связь между ними. Обычно такую роль играют сетевые службы и
приложения, в том числе Web-серверы.
Третье звено – система управления базами данных (СУБД), относящаяся к категории серверов баз данных. Данный сервер не работает напрямую с клиентскими программами, что повышает безопасность информации в системе.
Рисунок 1.3 – DFD-декомпозиция процесса «Формирование заказа» «КАК ЕСТЬ» (2-й уровень)
Данная модель является основой для анализа и дальнейшего совершенствования бизнес-процесса управления заказами клиентов ресторана.
1.3.2 Анализ недостатков существующего бизнес-процесса и рекомендации по его усовершенствованию с помощью интернет-
технологий
Анализ модели «КАК ЕСТЬ» показал, что существующий бизнес-процесс малоэффективен и имеет следующие недостатки:
− невысокая эффективность маркетинга ресторана, обусловленная отсутствием собственного Web-представительства;
− отсутствие возможности онлайнового режима ввода заказов клиентами.
С учетом вышеизложенного принято решение улучшить бизнес-процесс
путем разработки и внедрения Web-представительства ООО «Честер», обеспечивающего возможность онлайнового режима ввода заказов клиентами.
1.3.3 Разработка модели «КАК ДОЛЖНО БЫТЬ» бизнес-процесса управления заказами ООО «Честер»
На рисунках 1.4-1.6 представлена модель «КАК ДОЛЖНО БЫТЬ» бизнес-процесса управления заказами ОО «Честер» (разработанная с помощью методологий IDEF0 и DFD.
Рисунок 1.4 – Контекстная диаграмма бизнес-процессов управления заказами
ООО «Честер» «КАК ДОЛЖНО БЫТЬ» (0-й уровень)
На представленной диаграмме изображены следующие элементы: − входные данные: Онлайн-заказ;
− выходные данные: Чек, Отметка о выполнении заказа;
− управляющие воздействия: Закон РФ «О защите прав потребителей», Инструкция по управлению заказами клиентов;
− исполнители: Клиент, Работник ресторана, Web-представительство.
Рисунок 1.5 – DFD-диаграмма бизнес-процесса управления заказами ООО «Честер» «КАК ДОЛЖНО БЫТЬ» (1-й уровень)
Новые и измененные элементы выделены красным цветом.
Рисунок 1.6 – DFD-декомпозиция процесса «Формирование заказа» «КАК
ДОЛЖНО БЫТЬ» (2-й уровень)
Таким образом, усовершенствование исследуемого бизнес-процесса достигается путем разработки и внедрения Web-представительства, отвечающего требованиям заказчика.
Глава 2 Разработка web-представительства ООО
«Честер».
2.1 Проектирование базы данных Web-представительства Логическое моделирование предназначено для создания объектной
модели программной архитектуры системы и логической модели данных.
Для обоснования и постановки задачи на разработку логической модели данных Web-представительства используется методология объектно-ориентированного проектирования и анализа, основанная на языке UML [12].
В концепции UML для описания системы с различных точек зрения используются три типа моделей: функциональная, модели классов и модель взаимодействий.
Полное описание системы требует наличия всех трех моделей.
Каждая модель применяется на всех этапах проектирования и строится с помощью специальных диаграмм языка UML.
2.1.1 Диаграмма вариантов использования бизнес-процесса
управления заказами клиентов
На первом этапе строим диаграмму вариантов использования, которая представлена на рисунке 2.1.
Диаграммы вариантов использования (use case diagram) применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к проектируемой системе при ее проектировании и разработке. Диаграмма вариантов использования строится на основе DFD-декомпозиции бизнес-процесса управления заказами «КАК ДОЛЖНО БЫТЬ», представленной на рисунке 1.5.
Рисунок 2.1 – Диаграмма вариантов использования бизнес-процесса
управления заказами клиентов ООО «Честер» «КАК ДОЛЖНО БЫТЬ»
Диаграмма вариантов использования описывает функциональный аспект рассматриваемой информационной системы «КАК ДОЛЖНО БЫТЬ», предоставляя дополнительную информацию об отношениях между различными вариантами использования и внешними пользователями-актерами.
2.1.2 Диаграмма классов Web-представительства Диаграмма классов описывает статическую структуру объектов системы
и их отношения. Эта модель определяет контекст разработки программы, то есть предметную область. Модель классов изображается на диаграммах классов. Диаграмма классов – это граф, вершинами которого являются классы, а ребрами – их отношения.
Построение диаграммы классов системы производится следующим образом:
25
в описании классов выделяются кандидаты в классы
– существительные, которые потенциально могут соответствовать классам (при этом следует помнить, что существительные могут относиться к объектам, ассоциациям или атрибутам классов);
анализируются роли кандидатов в системе. Каждый класс должен выполнять некоторые действия и взаимодействовать с другими классами. Он должен иметь также уникальное имя, отражающее характер абстракции, представляемой данным классом.
На рисунке 2.2 изображена диаграмма классов Web-представительства.
Рисунок 2.2 – Диаграмма классов Web-представительства
Спецификация классов:
Клиент – класс объектов-пользователей Web-представительства, выполняющих ввод онлайновых заказов;
Работник ресторана – класс объектов-пользователей Web-представительства, формирующих чеки и обслуживающих заказы клиентов;
Заказ – класс объектов-документов; Чек – класс объектов-документов.
Представленная диаграмма предназначена для разработки объектной
модели приложения Web-представительства.
2.1.3 Диаграмма последовательности бизнес-процесса управления
заказами
Диаграмма последовательности (sequence diagram) отображает динамический аспект системы, представлена на рисунке 2.3.
В рамках динамического аспекта реализуется ситуационный подход, позволяющий решить следующие задачи:
определение способов выполнения процесса в зависимости от конкретной ситуации. Выбор способа реализации (сценария) определяется с привлечением того или иного ответственного исполнителя (актера);
определение взаимодействия организационного, функционального и элементного аспектов;
определяется документооборот (обмен сообщениями) между взаимодействующими исполнителями.
Рисунок 2.3 – Диаграмма последовательности бизнес-процесса управления заказами клиентов ресторана
В случайный момент времени объект Клиент отправляет объекту Работник ресторана сообщение «Открыть заказ».
Объект Работник ресторана формирует чек и отправляет его объекту
Клиент по электронной почте с сообщением «Оплатить чек».
Объект Клиент оплачивает чек и отправляет объекту Работник ресторана подтверждение оплаты чека.
Объект Работник ресторана сообщает объекту Клиент о подтверждении заказа.
2.2 Разработка логической модели данных Web-сайта
Логическая модель данных является начальным прототипом будущей
базы данных.
Логическая модель данных – описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы [8].
Логическая модель данных строится в терминах информационных единиц, но без привязки к конкретной СУБД.
Логическая модель данных строится на основе диаграммы классов, представленной на рисунке 2.2, которая трансформируется в ER-модель («сущность-связь»).
Затем в модель добавляются новые сущности, необходимые для обеспечения необходимого уровня нормализации данных.
На рисунке 2.4 изображена логическая модель данных Web-представительства, разработанная в методологии IDEF1X.
Как следует из рисунка, в процессе разработки выделены следующие основные сущности:
− Клиент; − Заказ;
− Работник ресторана; − Чек
Рисунок 2.4 – Логическая модель данных Web-представительства
Дополнительные сущности Учетная запись, Статус, Меню и Бригада
введены для приведения модели к уровню нормальной формы Бойса-Кодда. Между основными сущностями логической модели установлены
следующие связи:
− Клиент может сделать несколько Заказов («один ко многим»);
− Работник ресторана может обслужить несколько Заказов («один ко многим»);
− По каждому заказу может быть сформирован только один Чек («один к одному»).
Все связи между основными сущностями неидентифицирующие. Представленная логическая модель данных является концептуальной
моделью данных Web-представительства и будет использована в качестве основы при проектировании реляционной модели базы данных системы на стадии физического моделирования данных.
2. 3. Выбор архитектуры Web-представительства
Информационные системы, разрабатываемые с помощью Web- технологий, реализуются в архитектуре «клиент-сервер» [4].
Архитектура «клиент-сервер» может быть представлена в следующих вариантах:
1. Традиционная двухзвенная архитектура «клиент - сервер».
Первое звено – клиентские компьютеры с прикладными программами, с помощью которых пользователи обращаются по сети к базе данных.
Второе звено – сервер баз данных, также участвующий в обработке данных.
Благодаря двухзвенной архитектуре снижается нагрузка на информационную сеть, поскольку передаются только запросы и ответы на них.
Преимущества:
распределение функций вычислительной системы между несколькими независимыми компьютерами в сети, это позволяет упростить обслуживание вычислительной системы, в частности, замена, ремонт, модернизация или перемещение сервера, не затрагивают клиентов;
все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов;
на сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа.
Недостатки:
ограниченность применения для Web-приложений; высокая стоимость оборудования клиентов.
2. Трехзвенная архитектура «клиент - сервер».
Первое звено – клиентская программа. Клиент посылает запросы на выполнение нужных действий. Вся логика системы реализуется на других уровнях, поэтому требования к клиентской машине минимальные. Такие
клиентские программы называют тонкими клиентами. В качестве базового
программного обеспечения используются Web-браузеры- IE, Mozilla и другие. Второе звено – сервер приложений – программное обеспечение
промежуточного уровня. Синхронизирует работу компонентов всей системы и организует связь между ними. Обычно такую роль играют сетевые службы и
приложения, в том числе Web-серверы.
Третье звено – система управления базами данных (СУБД), относящаяся к категории серверов баз данных. Данный сервер не работает напрямую с клиентскими программами, что повышает безопасность информации в системе.