Электронное кафе

Диаграмма состояния данной системы приведена в приложении В на рисунке В.1

 

3.3 Диаграмма последовательностей

 

Для моделирования взаимодействия объектов во времени в языке UML используются диаграммы последовательностей. Для демонстрации диаграммы последовательностей рассмотрим диаграмму, представленную в приложении Г на рисунке Г.1.

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

Изъяном данной диаграммы является то, что в программе Enterprise Architect данный тип диаграммы выполняется, не совсем точно, т.к. линия жизни каждого блока должна заканчиваться после того, как была проведена стрелка от этого объекта, но в программе линия жизни ещё продлевается.

 

3.4 Диаграммы классов

 

Диаграмма классов описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов[3].

В приложении Д на рисунке Д.1 изображена диаграмма классов и интерфейсов уровней rmi-service-dao.

 

3.5 Диаграмма компонентов

 

Диаграмма компонентов показывает разбиение программной системы на структурные компоненты и связи между компонентами[3].

В приложении Е на рисунках Е.1 и Е.2 приведены диаграммы компонентов клиентской и серверной частей данного приложения с пакетами и входящими в них классами, а также зависимость между данными классами.

 

6. Диаграмма развёртывания

 

Диаграмма развёртывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения[3].

В приложении Ж на рисунке Ж.1 приведена диаграмма развёртывания данной системы.

4 ИНФОРМАЦИОННАЯ МОДЕЛЬ СИСТЕМЫ И ЕЁ

   ОПИСАНИЕ

 

4.1 Информационная модель

 

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

Процесс построения информационной модели состоит из следующих шагов:

- определение сущностей;

- определение зависимостей между сущностями;

- задание первичных и альтернативных ключей;

- определение атрибутов сущностей;

- составление логической (logical)  модели;

- переход к физическому (physical) описанию модели.

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

На рисунке 4.1.1 представлена логическая модель данной системы

 

 

Рисунок 4.1.1 - Логическая модель системы

 

Проанализировав данную предметную область, в проекте было решено  создать  следующие сущности: Блюдо, Заказ, ТипБлюда,  Корзина, Состав, Продукт, Скидка, Клиент, Администратор, и входящие в них атрибуты:

- Блюдо содержит информацию  о блюде в меню:

1. `idDish` - уникальный номер блюда (первичный ключ);
2. `nameDish` - название блюда;
3. `priceDish` - стоимость блюда;
4. `weightDish` - вес блюда;
5. `imagespath` - путь к картинке блюда.

 

- Заказ содержит информацию  о заказе:

1. `idOrder` - уникальный номер заказа (первичный ключ);
2. `dishCostOrder` - стоимость за блюда;
3. `secondaryCostOrder` - дополнительная стоимость (приборы, упаковка).

         

- ТипБлюда содержит информацию  о типе блюда :

1. `idDishType` - уникальный номер типа блюда (первичный ключ);
2. `nameDishType` - название типа блюда.

 

- Продукт :

1. `idProduct` - уникальный номер продукта (первичный ключ);
2. `nameProduct` - название продукта;
3. `caloriesPer100grProduct` - калорийность продукта на 100 грамм.

 

• Состав – сущность, хранящая данные о составе блюда:

1. `productWieghtInDishComposition` - вес продукта в блюде;

2. `caloriesComposition` - калорийность продукта.

 

• Корзина:

1. `dshCountBasket` - количество выбранного блюда;

2. `dish_idDish` - код блюда;
3. `order_idOrder` - код заказа.

 

- Скидка:

1. `iddiscount` - уникальный номер скидки (первичный ключ);
2. `amountdiscount` - сумма скидки;
3. `percentdiscount` - процент скидки.

 

• Клиент – сущность, хранящая данные о клиенте:

1. ‘idClient` уникальный номер клиента (первичный ключ);

2. `lastnameClient`- фамилия клиента;
3. `firstnameClient` - имя клиента;
4. `addressClient`- адрес клиента;
5. `phoneClient` - телефон клиента.

 

• Администратор – сущность, хранящая данные об администраторе:
1. `idadmin` - уникальный номер администратора (первичный ключ);
2. `loginadmin`- логин;
3. `passwordadmin`- пароль.

 

 

Рисунок 4.1.2 - Физическая модель системы

 

4.2 Доказательство приведения информационной модели к 3-ей нормальной форме

 

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

 

 

Рисунок 4.2.1 - Первая нормальная форма

 

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

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

 

 

Рисунок 4.2.2 - Вторая нормальная форма

 

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

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

Для  приведения сущности к третьей нормальной форме необходимо:

- выделить атрибуты, которые функционально зависят от одного и того же не ключевого атрибута;

- поместить их в новую сущность;

- установить с новой сущностью связь типа «один ко многим»;

- повторить указанные выше операции, если это необходимо.

Проанализировав данную систему,  можно сказать, что данная модель находится в третьей нормальной форме, т.к. есть такие сущности, как на рисунке 4.2.3.

 

 

Рисунок 4.2.3 - Третья нормальная форма

 

5 ОБОСНОВАНИЕ ОРИГИНАЛЬНЫХ РЕШЕНИЙ ПО                        ИСПОЛЬЗОВАНИЮ ТЕХНИЧЕСКИХ И ПРОГРАММНЫХ СРЕДСТВ

 

При реализации данной программы были использованы следующие, не включённые в требования, решения:

1. Использование шаблона MVC (Model-View-Controller),

реализация, которого позволила чётко и структурировано разграничить части программы, что способствует удобной и быстрой расширяемости[1].

 Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

- Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя своё состояние.

- Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

- Поведение (Controller). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции.

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

2. Использование порождающего шаблона  SingleTon, который

удобен тем, что класс контролирует наличие единственного экземпляра, и он же предоставляет при необходимости к нему доступ[1].

3. Использование шаблона DAO (Data Access Object), реализация

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

4. Использование библиотеки JSTL (стандартная библиотека тегов

JSP). Она является альтернативой такому виду встроенной в JSP логики, как скриптлеты, то есть прямые вставки Java кода. Использование стандартизованного множества тегов предпочтительнее, поскольку получаемый код легче поддерживать и проще отделять бизнес-логику от логики отображения.

5. Использование шаблона Command, реализация которого

позволила легко обрабатывать и разграничивать запросы, приходящие от котроллера. Позволяет создать структуру, в которой класс-отправитель и класс-получатель не зависят друг от друга напрямую. Организация обратного вызова к классу, который включает в себя класс-отправитель[1].

6. Использование пула соединений с базой данных, что позволяет

контролировать количество  соединений и  с лёгкостью управлять соединениями (добавлять новое, удалять все).

7. Использование сессий позволило обеспечить хранение данных во

время нескольких запросов от клиента[1].

 

 

 

 

6. ОПИСАНИЕ АЛГОРИТМОВ РЕАЛИЗУЮЩИХ БИЗНЕС-ЛОГИКУ СЕРВЕРНОЙ ЧАСТИ ПРОЕКТИРУЕМОЙ СИСТЕМЫ

 

Бизнес-логика данного проекта, как было написано в требованиях, сосредоточена в серверной части. Там реализованы такие операции, как соединение с базой данных, добавление данных  в базу, удаление записей  из неё, чтение  и редактирование данных. Когда пользователь выбирает определенную операцию,  клиент вызывает соответствующие методы rmi-интерфейса, передавая в качестве параметров необходимые данные. После того, как клиент вызвал метод,  сервер получит информацию, он обрабатывает данный запрос, связывается с базой данных, если ему это требуется, и посылает клиенту результат его работы.

 

6.1 Добавление заказа в базу данных

 

Для того чтобы наглядно отобразить алгоритм, реализующий бизнес-логику северной части  системы «Сервис электронного кафе», я рассмотрю  пример добавления заказа в базу данных, блок-схема которого представлена в Приложении И на рисунке И.2, а листинг в Приложении Л.

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

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