Заключение

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

• Rational Unified Process (RUP), разработанная и поддерживаемая компанией IBM Rational Software

• Microsoft Solutions Framework (MSF), разработанная и поддерживаемая компанией Microsoft

• Application Lifecycle Management (ALM), разработанная и поддерживаемая компанией Borland

• Extreme Programming (XP) – экстремальное программирование, поддерживаемое открытым сообществом независимых разработчиков

Литература

1. Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose. Учебное пособие. - издательство "Интуит", 2006, 320 с.

2. Ларман Крэг Применение UML и шаблонов проектирования: Пер. с англ. : Уч. пос. – М.: Издательский дом «Вильямс», 2001. – 496 с.: ил.

3. С.Орлов Технологии разработки программного обеспечения. Учебное пособие. 2-е изд. – СПб.: Питер, 2003. – 480 с.:ил.

4. Уэнди Боггс, Майкл Боггс UML и Rational Rose^©: Пер.с англ. – М.: Издательство «ЛОРИ», 2000. – 581 с.

5. UML for Java Programmers Robert Cecit Martin Object Mentor Inc. Prentice Hall, Englewood Cliffs, New Jersey 07632, 2002, 236 pp.

6. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.

Приложение

Пример разработки

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

Система розничной торговли

Терминальная система торговой точки POST (Point-of-sale Terminal) – компьютеризированная система организации товарооборота и обработки платежей магазина.

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

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

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

• Представление – графический интерфейс и диалоговые окна.

• Логика приложения – включает объекты предметной области и удовлетворяет требованиям к системе.

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

• Хранение информации – база данных.

Требования

Общая формулировка задачи: создание терминальной торговой системы.

Потребители: Компания «Магазин ****», межнациональный распространитель **** товаров.

Цели

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

• Быстрое обслуживание клиентов

• Быстрый и точный анализ торговой деятельности предприятия

• Автоматическая инвентаризация товаров.

Функции системы

Основные функции:

1.1. Запись информации о текущей покупке – количество единиц товара

1.2. Вычисление общей стоимости покупки с учетом налогов

1.3. Считывание информации о товаре со штрих-кода с помощью сканера или ввод кода товара вручную

1.4. Уменьшение количества единиц товара после выполнения покупки

1.5. Регистрация выполненной покупки

1.6. Регистрация пользователей в системе на основе идентификатора пользователя и пароля

1.7. Поддержка базы данных

1.8. Обеспечение механизма взаимодействия между процессами и подсистемами

1.9. Отображение цены и описания выбранного товара.

Функции обеспечения платежей:

2.1. Обработка платежей наличными, считывание количества купленных единиц товара и вычисление баланса

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

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

2.4. Регистрация кредитных платежей в системе авторизации кредитов.

Атрибуты системы

Для функции 1.9. Отображение цены и описания выбранного товара:

• Время отклика – не более 5 с.

• Стиль интерфейса – цветной, основанный на формах.

Для функции 2.4. Регистрация кредитных платежей в системе авторизации кредитов:

• Отказоустойчивость – кредитные платежи должны обрабатываться в течение 24 ч даже при сбоях напряжения в сети.

• Время отклика – не более 10 с.

Диаграмма вариантов использования

Диаграмма вариантов использования для системы розничной торговли в общем виде представлена на рис. П.1.

Рис.П.0.97. Диаграмма вариантов использования в общем виде

В дальнейшем диаграмма вариантов использования может быть детализирована. На рис. П.2. представлена диаграмма на которой вариант использования Buy Items детализирован. Предполагается что оплата может осуществляться разными способами (наличными, кредитной карточкой, чеком).

Рис.П.0.98. Детализированная диаграмма вариантов использования

Описание вариантов использования

В качестве примера рассмотрим описание вариантов использования Buy Items и Start Up.

Вариант использования высокого уровня: Buy Items (Покупка товаров)

Вариант использования	Buy Items (Покупка товаров)
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир)
Тип	Основной
Описание	Покупатель подходит к кассе с товарами, которые он желает приобрести. Кассир вводит информацию о товаре и оформляет оплату. В завершение покупатель покидает магазин с приобретенными товарами.

Вариант использования высокого уровня: Start Up (Включение)

Вариант использования	Start Up (Включение)
Актеры	Manager (Менеджер)
Тип	Основной
Описание	Менеджер включает систему POST для его дальнейшего использования кассирами и проверяет правильность системной даты и времени, после чего система считается готовой к использованию.

Описание вариантов использования в развернутом формате:

Главный раздел варианта использования Buy Items

Вариант использования	Buy Items (Покупка товаров)
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир)
Цель	Оформление покупки и платежа
Описание	Покупатель подходит к кассе с товарами, которые он желает приобрести. Кассир вводит информацию о товаре и оформляет платеж, возможно, авторизованный. Покупатель покидает магазин с покупками.
Ссылки	Функции: 1.1, 1.2, 1.3, 1.7, 1.9, 2.1, 2.2, 2.3, 2.4 Варианты использования: Кассир должен предварительно реализовать вариант использования Log In (Регистрация).

Раздел Типичный ход событий варианта использования Buy Items

Типичный ход событий
Действия актера	Отклик системы
1. Покупатель подходит к кассовому аппарату с выбранными товарами.
2. Кассир вводит информацию о каждом товаре.	3. Определяет цену единицы товара и добавляет информацию о товаре, требуемую для выполнения транзакции.
Если покупатель приобретает несколько единиц одного и того же товара, то кассир также вводит их количество.	Выводится описание товара и его цена.
4. После завершения ввода информации о товаре кассир уведомляет об этом систему POST.	5. Вычисляет и отображает общую стоимость покупки.
6. Кассир сообщает покупателю общую стоимость покупки.
7. Покупатель выбирает тип платежа: Если выбрана оплата наличными, см. раздел «Оплата наличными». Если выбрана оплата по кредитной карточке, см. раздел «Оплата по кредитной карточке». Если выбрана оплата чеком, см. раздел «Оплата чеком».
	8. Регистрирует сделанную покупку.
	9. Обновляет сведения о наличии и количестве товара.
	10. Генерирует и выдает товарный чек.
11. Кассир выдает покупателю товарный чек.
12. Покупатель покидает магазин с приобретенными товарами
Альтернативный ход событий
2. Введен неверный идентификатор товара. – Выдать сообщение об ошибке.
7. Покупатель не может оплатить покупку. – Отменить транзакции, связанной с данной продажей.

Раздел «Оплата наличными»
Типичный ход событий
Действия актера	Отклик системы
1. Покупатель передает кассиру деньги, количество которых, возможно, превышает общую стоимость платежа.
2. Кассир вводит полученную сумму	3. Отображает сумму, которую требуется вернуть покупателю (сдачу).
4. Кассир кладет полученные от покупателя деньги в кассу и извлекает причитающуюся ему сдачу. Кассир передает покупателю сдачу.
Альтернативный ход событий
1. У покупателя недостаточно наличных денег. – Можно отменить покупку или инициировать другой способ платежа.
4. В кассе недостаточно денег для выдачи сдачи. – Кассир запрашивает недостающую сумму в вышестоящей организации или просит покупателя поискать более мелкие купюры либо изменить способ оплаты.

Раздел «Оплата по кредитной карточке»
Типичный ход событий
Действия актера	Отклик системы
1. Покупатель сообщает информацию, необходимую для оформления оплаты по кредитной карточке.	2. Генерирует запрос на оформление оплаты по кредитной карточке и отправляет его внешней службе авторизации кредитов CAS (Credit Authorization Service).
3. Служба авторизации кредитов авторизует оплату.	4. Получает подтверждение на выполнение платежа от службы авторизации кредитов.
	5. Заносит информацию об оплате по кредитной карточке и подтверждение от службы CAS в систему оплаты кредитов A/R (Accounts Receivable). (Служба авторизации кредитов выделяет деньги на оплату покупки, а система оплаты кредитов должна перечислить необходимую сумму на счет магазина).
	6. Отображает сообщение об успешной авторизации.
Альтернативный ход событий
3. В ответ на запрос получен отказ от службы авторизации кредитов. – Предложить покупателю другой способ оплаты.

Раздел «Оплата чеком»
Типичный ход событий
Действия актера	Отклик системы
1. Покупатель выписывает чек и идентифицирует себя.
2. Кассир вводит в систему необходимую информацию и направляет запрос на авторизацию оплаты чеком.	3. Генерирует запрос на оплату чеком и отправляет его в службу авторизации чеков.
4. Служба авторизации чеков авторизует оплату.	5. Получает подтверждение на выполнение оплаты чеком от службы авторизации чеков.
	6. Отображает сообщение об успешной авторизации.
Альтернативный ход событий
4. В ответ на запрос получен отказ от службы авторизации чеков – Предложить покупателю другой способ оплаты.

Варианты использования, упорядоченные по приоритетам.

Высокий	Buy Items (Покупка товаров)	Наиболее высокая степень удовлетворения критериям упорядочивания по приоритетам
Средний	Add New Users (Добавление новых пользователей)	Влияет на подсистему безопасности
	Log In (Регистрация)	Влияет на подсистему безопасности
	Refund Items (Возврат товара)	Важный процесс, влияет на инвентаризацию
Низкий	Cash Out (Расчет)	Влияние на архитектуру минимальное
	Start Up (Включение)	Определение зависит от других вариантов использования
	Shut Down (Выключение)	Влияние на архитектуру минимальное

Сложные варианты использования необходимо переопределить в терминах нескольких версий, соответствующих нескольким циклам разработки, например:

• Buy Items (Покупка товара): версия 1 – оплата наличными, без инвентаризации, ...

• Buy Items (Покупка товара): версия 2 – все типы платежей

• Buy Items (Покупка товара): версия 3 – полная версия, включая инвентаризацию.

В качестве примера приведем первую итерацию разработки и начало второй.

ИТЕРАЦИЯ 1

АНАЛИЗ (1)

Buy Items (Покупка товара): версия 1

Упрощения, цели и предположения:

• Оплата только наличными;

• Инвентаризация не поддерживается;

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

• Ввод универсального кода товара без сканера для считывания штрих-кода;

• Вычисление налогов не производится;

• Кассир не должен регистрироваться – без контроля доступа;

• Не поддерживается база данных отдельных покупателей;

• Без контроля выдачи товарных чеков;

• На чеке указываются название и адрес магазина, дата и время покупки;

• Идентификатор кассира и код версии системы на чеке не отображаются;

• Сделанные покупки регистрируются в журнале.

Главный раздел

Вариант использования	Buy Items (Покупка товаров): версия 1
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир)
Цель	Оформление покупки и платежа наличными
Описание	Покупатель подходит к кассе с товарами, которые он желает приобрести. Кассир вводит информацию о товаре и оформляет платеж. В завершение покупатель покидает магазин с приобретенными товарами.
Ссылки	Функции: 1.1, 1.2, 1.3, 1.5, 1.7, 1.9, 2.1

Типичный ход событий
Действия актера	Отклик системы
1. Покупатель подходит к кассовому аппарату с POST с товарами, которые он желает приобрести.
2. Кассир вводит универсальный код для каждого товара.	3. Определяет цену единицы товара и добавляет информацию о товаре для выполнения транзакции.
Если покупатель приобретает несколько единиц одного и того же товара, то кассир также вводит их количество.	Выводится описание товара и его цена.
4. После завершения ввода информации о товаре кассир уведомляет систему POST, что информация введена.	5. Вычисляет и отображает общую стоимость покупки.
6. Кассир сообщает покупателю общую стоимость покупки.
7. Покупатель дает деньги за покупку, количество которых, возможно, превышает общую стоимость платежа.
8. Кассир вводит полученную сумму	9. Отображает сумму, которую требуется вернуть покупателю (сдачу) и выдает товарный чек.
10. Кассир кладет полученные от покупателя деньги в кассу и извлекает причитающуюся ему сдачу. Кассир отдает покупателю сдачу и товарный чек.
12. Покупатель покидает магазин с приобретенными товарами

Объекты и атрибуты системы POST

Объекты	Атрибуты
POST (торговая точка, оснащенная системой POST)
Item (Товар)
Store (Магазин)	address: Address (адрес магазина) name: Text (название магазина)
Sale (Продажа)	date: Date (дата покупки) time: Time (время покупки) total: Quantity (итоговая сумма продажи)
Payment (Платеж)	amount: Quantity (предложенная покупателем сумма)
ProductCatalog (Каталог товаров)
ProductSpecification (Спецификация товара)	description: Text (описание товара) upc: Upc (универсальный код товара) price: Quantity (цена товара)
SaleLineItem (Элемент продажи)	quantity: Integer (количество единиц приобретаемого товара)
Cashier (Кассир)
Customer (Покупатель)
Manager (Менеджер)

На рис. П.3 представлена концептуальная модель предметной области системы розничной торговли.

Рис.П.0.99. Концептуальная модель предметной области

Диаграмма последовательности для варианта использования Buy Items (Покупка товаров) может иметь вид, представленный на рис. П.4.

Рис.П.0.100. Диаграмма последовательности для варианта использования Buy Items.

Описание системных операций приведено ниже.

ПРОЕКТИРОВАНИЕ (1)

В качестве примеров приведем описания и диаграммы кооперации для системных событий enterItem, endSale, makePayment варианта использования Buy Items и для системного события startUp варианта использования Start Up.

Описание операции enterItem

	Описание
Имя	enterItem (ups: Number, quantity: Integer)
Обязанности	Ввести (записать) информацию о продаже товара и добавить ее к общей информации о текущей продаже. Отобразить описание товара и его цену.
Тип	Системная
Ссылки	Функции системы: 1.1, 1.3, 1.9 Варианты использования: Buy Items
Примечания	Использовать самый быстрый доступ к базе данных
Исключения	Если универсальный код товара указан неправильно, выдать сообщение об ошибке
Вывод
Предусловия	Универсальный код товара известен системе
Постусловия	Для новой продажи создан экземпляр объекта Sale (создание экземпляра) Для новой продажи вновь созданный экземпляр Sale связан с объектом POST (формирование ассоциации) Создан экземпляр объекта SalesLineItem (создание экземпляра) Вновь созданный экземпляр SalesLineItem связан с объектом Sale (формирование ассоциации) Атрибут SalesLineItem.quantity принял значение quantity (модификация атрибута) Объект SalesLineItem связан с объектом ProductSpecification на основе соответствия универсального кода товара (формирование ассоциации)

Диаграмма кооперации для операции enterItem

Для построения диаграммы кооперации вначале необходимо выбрать контроллер для обработки сообщений системной операции enterItem. Согласно паттерну Controller в качестве такового можно выбрать класс POST. В качестве параметров сообщения enterItem объекту POST передаются универсальный код товара и количество покупаемых единиц.

Из постусловий 1 и 2 вытекает необходимость назначения некоторому объекту обязанности создания экземпляров других объектов. Согласно паттерну Creator, запись информации о продажах может выполнять объект POST, поэтому ему поручим создание экземпляров объектов Sale, в этом случае объект POST будет содержать ссылку на текущий экземпляр Sale.

После создания объекта Sale необходимо создать пустой набор (контейнер) для записи всех добавляемых впоследствии экземпляров SalesLineItem. Этот контейнер будет поддерживаться экземпляром Sale, который согласно паттерну Creator является наилучшим кандидатом для их создания. Контейнер представлен на диаграмме мультиобъектом.

Из постусловий 1 и 2 системной операции enterItem следует необходимость делегирования обязанности по созданию экземпляра SalesLineItem. Так как объект Sale содержит объекты SalesLineItem, то логично именно этому классу поручить создание экземпляров SalesLineItem. В таком случае со временем объект Sale будет связан с новым экземпляром набора продаваемых товаров.

Из постусловий следует, что при создании экземпляра SalesLineItem необходимо указать количество единиц покупаемого товара, поэтому данное значение надо передавать из объекта POST объекту Sale, который в свою очередь, передаст его в качестве параметра сообщения create.

Согласно паттерну для создания объекта SalesLineItem объекту Sale передается сообщение makeLineItem, параметрами которого являются количество единиц товара quantity и спецификация товара ProductSpecification, соответствующая универсальному коду товара. Объект Sale создает экземпляр SalesLineItem, а затем хранит этот новый экземпляр в своем постоянном контейнере.

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

Экземпляры объектов POST и ProductCatalog должны быть созданы в процессе реализации варианта использования Start Up и между этими объектами должна устанавливаться постоянная связь. Поэтому отправку сообщения с запросом на получение значения спецификации – specialization можно поручить классу POST для класса ProductCatalog.

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

Также необходимо определить сообщения мультиобъектам (отправляется один раз целому набору данных, а не отдельным элементам):

• find – сообщение, передаваемое мультиобъекту ProductSpecification.

• create – сообщение, передаваемое мультиобъекту SalesLineItem для создания контейнера, представленного мультиобъектом.

• add – сообщение, передаваемое мультиобъекту SalesLineItem для добавления элемента в контейнер, представленный мультиобъектом.

Диаграмма представлена на рис. П.5.

Рис. П.0.101. Диаграмма кооперации для операции enterItem

Описание операции endSale

	Описание
Имя	endSale()
Обязанности	Зафиксировать окончание ввода наименований товара и отобразить общую стоимость покупки
Тип	Системная
Ссылки	Функции системы: 1.2 Варианты использования: Buy Items
Примечания
Исключения	Если продажа не состоялась, выдать сообщение об ошибке
Вывод
Предусловия	Универсальный код товара известен системе
Постусловия	Атрибут Sale.isComplete принял значение true (модификация атрибута)

Диаграмма кооперации для системной операции endSale

В соответствии с паттерном Controller в качестве контроллера будем использовать класс POST.

Обязанность установки атрибута isComplete объекта Sale в значение true согласно паттерну Expert следует возложить на сам класс Sale, так как он владеет атрибутом isComplete. Тогда класс POST будет отправлять объекту Sale сообщение becomeComplete, требующее установки этого атрибута равным true. Диаграмма представлена на рис. П.6.

Рис.П.0.102. Диаграмма кооперации для системной операции endSale

Вычисление общей стоимости покупки

Согласно паттерну Expert отвечать за вычисление общей стоимости продажи должен сам класс Sale, поскольку он обладает информацией обо всех экземплярах SalesLineItem, стоимость которых суммируется при вычислении общей стоимости. Вычисление общей стоимости реализовано в виде операции total.

Для вычисления общей стоимости покупки Sale необходимо знать стоимость каждого покупаемого товара SalesLineItem. Согласно паттерну Expert за это отвечает сам класс SalesLineItem, так как ему известно количество покупаемых единиц товара и спецификация этого товара. Данная обязанность реализована в виде операции subtotal.

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

Диаграмма кооперации для операции total представлена на рис. П.7.

Рис. П.0.103. Диаграмма кооперации для операции total

Сначала объекту Sale передается сообщение total. Затем объект Sale отправляет сообщение subtotal каждому связанному с ним экземпляру SalesLineItem. В свою очередь, каждый экземпляр SalesLineItem отправляет сообщение price связанному с ним объекту ProductSpecification. Передачу сообщения total объекту Sale должен осуществлять объект уровня представления, например аплет Java.

Описание операции makePayment

	Описание
Имя	makePayment (amount: Number или Quantity)
Обязанности	Ввести (записать) информацию о платеже, вычислить баланс и выдать чек.
Тип	Системная
Ссылки	Функции системы: 2.1 Варианты использования: Buy Items
Примечания
Исключения	Если сведения о продаже оказались неполными, выдать сообщение об ошибке
Вывод
Предусловия
Постусловия	Создан экземпляр объекта Payment (создание экземпляра) Атрибут Payment.amountTendered принял значение amount (модификация атрибута) Объект Payment связан с объектом Sale (формирование ассоциации) Объект Sale связан с объектом Store для его добавления в журнал регистрации (формирование ассоциации)

Диаграмма кооперации для системной операции makePayment

В соответствии с паттерном Controller в качестве контроллера будем использовать класс POST.

Согласно паттерну Creator одним из кандидатов на выполнение обязанности создания новых экземпляров может быть класс POST, так как он по логике записывает сведения о платежах. Другим кандидатом может быть класс Sale, так как он наиболее активно использует информацию объекта Payment.

Если рассмотреть эти варианты с точки зрения паттернов High Cohesion и Low Coupling, то если экземпляр объекта Payment создается классом Sale, то работа (обязанности) класса POST облегчается. Кроме того, классу POST не нужно знать о существовании экземпляра Payment, так как он может записывать его через объект Sale. Это обеспечит низкий уровень сцепления.

Диаграмма приведена на рис. П.8.

Рис.П.0.104. Диаграмма кооперации для системной операции makePayment

Сведения о приобретенных покупках должны заноситься в журнал регистрации. Согласно паттерну Expert, всей необходимой информацией обладает объект Store, поскольку он связан с финансовой деятельностью предприятия.

Диаграмма кооперации для регистрации покупки приведена на рис. П.9.

Рис. П.0.105. Диаграмма кооперации для регистрации покупки

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

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

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

Диаграмма представлена на рис. П.10.

Рис.П.0.106. Диаграмма кооперации вычисления баланса

Описание операции startUp

	Описание
Имя	startUp()
Обязанности	Инициализировать систему
Тип	Системная
Ссылки
Примечания
Исключения
Вывод
Предусловия
Постусловия	Созданы экземпляры объектов Store, POST, ProductCatalog и ProductSpecification (создание экземпляра) Объект ProductCatalog связан с объектом ProductSpecification (формирование ассоциации) Объект Store связан с объектом ProductCatalog (формирование ассоциации) Объект Store связан с объектом POST (формирование ассоциации) Объект POST связан с объектом ProductCatalog (формирование ассоциации)

Диаграмма кооперации для системной операции startUp

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

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

В качестве исходного специального объекта выбирается или класс, представляющий всю логическую систему (POST) или класс, представляющий всю организацию (Store). Выбор осуществляется на основе паттернов High Cohesion и Low Coupling. Выберем в качестве исходного объекта класс Store.

В реальном приложении экземпляры ProductSpecification должны храниться в базе данных. В процессе операции startUp они могут загружаться в оперативную память. Однако если таких объектов достаточно много, то лучше при необходимости загружать в память отдельные экземпляры этих объектов. Предположим, что экземпляры ProductSpecification каким-то образом помещаются в память объектом ProductCatalog.

Операция startUp включает события, происходящие после создания исходного объекта Store в результате отправки сообщения create().

Для создания объектов ProductCatalog и POST согласно паттерну Creator выбран объект Store, для создания объектов ProductSpecification – выбран объект ProductCatalog.

Диаграмма создания исходного специального объекта и последующих объектов представлена на рис. П.11.

Рис. П.0.107. Диаграмма создания исходного специального объекта и последующих объектов

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

В ходе анализа концептуальной модели и диаграмм взаимодействия строится диаграмма классов. Для системы розничной торговли диаграмма классов представлена на рис. П.12.

Рис.П.0.108. Диаграмма классов

КОНСТРУИРОВАНИЕ (1)

Классы необходимо реализовывать последовательно от минимально связанных с другими классами до максимально связанных.

В качестве средства реализации выбран язык программирования Java.

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

1. Payment

2. ProductSpecification

3. ProductCatalog

4. SalesLineItem

5. Sale

6. POST

7. Store

Класс Payment

package post;

public class Payment

{

private float amount;

public Payment (float cashTendered)

{ this.amount = cashTendered;}

public float getAmount() {return amount;}

}

Класс ProductSpecification

package post;

public class ProductSpecification

{

private int upc = 0;

private float price = 0;

private String description = “”;

public ProductSpecification

(int upc, float price, String description)

{

this.upc = upc;

this.price = price;

this.description = description;

}

public int getUPC() {return upc;}

public float getPrice() {return price;}

public String getDescription() {return description;}

}

Класс ProductCatalog

package post;

import java.util.*;

public class ProductCatalog

{

private Hashtable productSpecifications = new Hashtable();

public ProductCatalog()

{

ProductSpecification ps =

new ProductSpecification(100, 1, “товар 1”);

ProductSpecifications.put(new Integer(100), ps);

ps = new ProductSpecification(200, 1, “товар 3”);

ProductSpecifications.put(new Integer(200), ps);

}

public ProductSpecification getSpecification(int upc)

{

return (ProductSpecification)

ProductSpecifications.get(new Integer(upc));

}

}

Класс SalesLineItem

package post;

class SalesLineItem

{

private int quantity;

public ProductSpecification productSpec;

public SalesLineItem

(ProductSpecification spec, int quantity)

{

this.productSpec = spec;

this.quantity = quantity;

}

public float subtotal()

{

return quantity * productSpec.getPrice();

}

}

Класс Sale

package post;

import java.util.*;

class Sale

{

private Vector lineItems = new Vector();

private Date date = new Date();

private boolean isComplete = false;

private Payment payment;

public float getBalance()

{

return payment.getAmount()- total();

}

public void becomeComplete() {isComplete = true;}

public boolean isComplete() {return isComplete;}

public void makeLineItem

(ProductSpecification spec, int quantity)

{

lineItem.addElement(new SalesLineItem(spec, quantity));

}

public float total()

{

float total = 0;

Enumeration e = lineItems.elements();

while(e.hasMoreElements())

{ total += ((SalesLineItem)e.nextElement()).subtotal();}

return total;

}

public void makePayment(float cashTendered)

{ payment = new Payment(cashTendered)}

}

Класс POST

package post;

import java.util.*;

class POST

{

private ProductCatalog productCatalog;

private Sale sale;

public POST(ProductCatalog catalog)

{

productCatalog = catalog;

}

public void endSale()

{

sale.becomeComplete();

}

public void enterItem(int upc, int quantity)

{

if(isNewSale())

{

sale = new Sale();

}

ProductSpecification spec =

productCatalog.specification(upc);

sale.makeLineItem(spec, quantity);

}

public void makePayment(float cashTendered)

{

sale.makePayment(cashTendered);

}

private boolean isNewSale()

{

return (sale == null) || (sale.isComplete());

}

}

Класс Store

package post;

class Store

{

private ProductCatalog productCatalog = new ProductCatalog();

private POST post = new POST(productCatalog);

public POST getPOST() {return post;}

}

ИТЕРАЦИЯ 2

АНАЛИЗ (2)

Buy Items (Покупка товара): версия 2

Упрощения, цели и предположения:

• Инвентаризация не поддерживается;

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

• Ввод универсального кода товара без сканера для считывания штрих-кода;

• Вычисление налогов не производится;

• Система скидок не поддерживается;

• Кассир не должен регистрироваться – без контроля доступа;

• Не поддерживается база данных отдельных покупателей;

• Без контроля выдачи товарных чеков;

• На товарном чеке указываются название и адрес магазина, дата и время покупки;

• Идентификатор кассира и идентификатор версии системы на чеке не отображаются;

• Сделанные покупки регистрируются в журнале.

• Для каждой продажи используется единственный тип платежа

• Все платежи выполняются полностью: не поддерживается частичная оплата или оплата в кредит

• Выполняется авторизация платежей чеком и по кредитной карточке

• Для каждого типа кредитной карточки задействуется своя служба кредитной авторизации (Visa, MasterCard, …)

• Для всех чеков используется единая служба инвентаризации

• Терминал системы розничной торговли отвечает за взаимодействие со службой авторизации кредитных карточек. Устройство считывания кредитных карточек – устройство, функции которого сводятся к отправке информации на терминал.

• Взаимодействие с внешними службами осуществляется через модем. При каждом соединении выполняется набор номера.

• Авторизация кредитных карточек выполняется банком.

• Сумма платежа по кредитной карточке и чеку в точности соответствует стоимости всей покупки

Start Up (Включение): версия 2

Упрощения, цели и предположения:

• Предполагается, что дата и время определены корректно.

• Для поддержки варианта использования Buy Items (Покупка товара) требуется минимальная инициализация

• Начальная информация для инициализации в базе данных не хранится

На данной итерации добавлены новые варианты использования, расширяющие вариант использования Buy Items (Покупка товара):

• Pay by Cash (Оплата наличными)

• Pay by Credit (Оплата по кредитной карточке)

• Pay by Check (Оплата чеком)

Новые понятия итерации 2

Exchange Items – Обмен товара

CreditCard – Кредитная карточка

Check – Чек

CashPayment – Оплата наличными

CreditPayment – Оплата по кредитной карточке

CheckPayment – Оплата чеком

CreditAutorizationService – Служба авторизации кредитных карточек

CheckAutorizationService – Служба авторизации чеков

AccountsReceivable – Система оплаты кредитов

Вариант использования: Buy Items (Покупка товаров) - 2

Вариант использования	Buy Items (Покупка товаров)
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир)
Тип	Основной
Описание	Покупатель подходит к кассе с товарами, которые он желает приобрести. Кассир вводит информацию о товаре и оформляет платеж. В завершение покупатель покидает магазин с приобретенными товарами.

Типичный ход событий
Действия актера	Отклик системы
1. Покупатель подходит к кассе с системой POST с выбранными товарами.
2. Кассир вводит информацию о каждом товаре.	3. Определяет цену единицы товара и добавляет информацию о товаре для выполнения транзакции.
Если выбрано несколько единиц одного и того же товара, то кассир вводит их количество.	Выводит описание товара и его цену.
4. После завершения ввода информации о товаре, кассир уведомляет об этом систему POST.	5. Вычисляет и отображает общую стоимость покупки.
6. Кассир сообщает покупателю общую стоимость покупки.
7. Покупатель выбирает тип платежа: Если выбрана оплата наличными, то инициировать вариант использования Pay by Cash (Оплата наличными). Если выбрана оплата по кредитной карточке, то инициировать вариант использования Pay by Credit (Оплата по кредитной карточке). Если выбрана оплата чеком, то инициировать вариант использования Pay by Check (Оплата чеком).
	8. Регистрирует сделанную покупку.
	9. Обновляет сведения о наличии и количестве товара.
	10. Генерирует и выдает товарный чек.
11. Кассир выдает покупателю товарный чек.
12. Покупатель покидает магазин с приобретенными товарами

Альтернативный ход событий

2. Введен неверный идентификатор товара. – Выдать сообщение об ошибке.

7. Покупатель не может оплатить покупку. – Отменить транзакции, связанной с данной продажей.

Связанные варианты использования

Pay by Cash; Pay by Credit; Pay by Check

Вариант использования: Pay by Cash (Оплата наличными)

Вариант использования	Pay by Cash (Оплата наличными)
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир)
Описание	Покупатель оплачивает покупку наличными

Типичный ход событий
Действия актера	Отклик системы
1. Покупатель решает оплачивать покупку наличными после сообщения ему общей стоимости покупки.
2. Покупатель вручает кассиру сумму, возможно превышающую общую стоимость покупки.
3. Кассир вводит в систему полученную сумму.	4. Отображает сумму причитающейся сдачи.
5. Кассир кладет полученные от покупателя деньги в кассу и извлекает причитающуюся ему сдачу. Кассир возвращает сдачу покупателю.
Альтернативный ход событий
2. У покупателя недостаточно наличных денег. – Можно отменить покупку или инициировать другой способ платежа.
3. В кассе недостаточно денег для выдачи сдачи. – Кассир запрашивает недостающую сумму в вышестоящей организации или просит покупателя поискать более мелкие купюры либо изменить способ оплаты.

Вариант использования: Pay by Credit (Оплата по кредитной карточке)

Вариант использования	Pay by Credit (Оплата по кредитной карточке)
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир), CreditAutorizationService (Служба авторизации кредитных карточек), AccountsReceivable (Система оплаты кредитов)
Описание	Покупатель оплачивает покупку по кредитной карточке. Платеж проверяется внешней службой авторизации платежей по кредитным карточкам. Информация направляется системе оплаты кредитов.

Типичный ход событий
Действия актера	Отклик системы
1. Покупатель решает оплачивать покупку по кредитной карточке после сообщения ему общей стоимости покупки.
2. Покупатель сообщает информацию, необходимую для оформления оплаты по кредитной карточке.	3. Генерирует запрос на оформление оплаты по кредитной карточке и отправляет его внешней службе авторизации кредитов CAS (Credit Authorization Service).
4. Служба авторизации кредитов авторизует оплату.	5. Получает подтверждение на выполнение платежа от службы авторизации кредитов.
	6. Заносит информацию об оплате по кредитной карточке и подтверждение от службы CAS в систему оплаты кредитов A/R (Accounts Receivable). (Служба авторизации кредитов выделяет деньги на оплату покупки, а система оплаты кредитов должна перечислить необходимую сумму на счет магазина).
	7. Отображает сообщение об успешной авторизации.
Альтернативный ход событий
4. В ответ на запрос получен отказ от службы авторизации кредитов. – Предложить покупателю другой способ оплаты.

Вариант использования: Pay by Check (Оплата чеком)

Вариант использования	Pay by Check (Оплата чеком)
Актеры	Customer (Покупатель) – инициатор, Cashier (Кассир), CheckAutorizationService (Служба авторизации чеков)
Описание	Покупатель оплачивает покупку чеком. Платеж проверяется внешней службой авторизации чеков.

Типичный ход событий
Действия актера	Отклик системы
1. Покупатель решает оплачивать покупку чеком после сообщения ему общей стоимости покупки.
2. Покупатель выписывает чек и идентифицирует себя.
3. Кассир вводит в систему необходимую информацию и направляет запрос на авторизацию оплаты чеком.	4. Генерирует запрос на оплату чеком и отправляет его в службу авторизации чеков.
5. Служба авторизации чеков авторизует платеж.	6. Получает подтверждение на выполнение оплаты чеком от службы авторизации чеков.
	7. Отображает сообщение об успешной авторизации.
Альтернативный ход событий
5. В ответ на запрос получен отказ от службы авторизации чеков – Предложить покупателю другой способ оплаты.

Ниже приведены примеры диаграмм последовательности для некоторых функций системы.

Стандартное начало диаграммы последовательности для варианта использования Buy Items (Покупка товаров) приведена на рис. П.13.

Рис П. 0.109 Стандартное начало варианта использования Buy Items

Диаграмма последовательности для оплаты по кредитной карточке приведена на рис. П.14.

Рис. 0.110. Диаграмма последовательности для оплаты по кредитной карточке

Диаграмма последовательности для оплаты чеком приведена на рис. П.15.

Рис. 0.111. Диаграмма последовательности для оплаты чеком

Ниже приведено описание системных операций.

Описание операции makeCashPayment полностью соответствует описанию операции makePayment, описанной на первой итерации.

Описание операции makeCreditPayment

	Описание
Имя	makeCreditPayment (ccNum:Number, expiryDate:date)
Обязанности	Сгенерировать и передать запрос на авторизацию при платеже по кредитной карточке
Тип (класс)	Системная
Примечания	Запрос должен быть преобразован в запись
Вывод	Если платеж осуществляется по кредитной карточке, то запрос должен быть передан службе авторизации кредитных карточек
Предусловия	Текущая продажа завершена
Постусловия	Создан экземпляр объекта pmt класса CreditPayment Объект pmt связан с текущим объектом Sale Создан экземпляр cc класса CreditCard, при этом cc.number=ccNum, cc.expiryDate=expiryDate Объект cc связан с объектом pmt Создан экземпляр cpr класса CreditPaymentRequest Объект pmt связан с объектом cpr Объект cpr связан с объектом CreditAutorizationService

Описание операции handleCreditReply

	Описание
Имя	handleCreditReply (reply:CreditPaymentReply)
Обязанности	Обработать ответ службы авторизации кредитных карточек. Если получено подтверждение, то завершить продажу и поместить запись о платеже в базу данных поступлений.
Тип (класс)	Системная
Примечания	Объект reply представляет собой запись, которая должна быть преобразована в объект CreditPaymentApprovalReply или CreditPaymentDenialReply
Вывод	Если получено подтверждение, то в базу данных поступлений помещается соответствующая информация
Предусловия	Службе авторизации кредитных карточек передается запрос на авторизацию
Постусловия	Если получено подтверждение: Создан экземпляр approval класса CreditPaymentApprovalReply Объект approval связан с объектом AccountsReceivable Объект Sale связан с объектом Store (в журнал регистрации добавлены данные о завершенных продажах) Если получен отказ: Создан экземпляр denial класса CreditPaymentDenialReply

Описание операции makeCheckPayment

	Описание
Имя	makeCheckPayment(driversLicenceNum:number)
Обязанности	Сгенерировать и передать запрос на авторизацию при платеже чеком
Тип (класс)	Системная
Примечания	Запрос должен быть преобразован в запись
Вывод
Предусловия	Текущая продажа завершена
Постусловия	Создан экземпляр объекта pmt класса CheckPayment Объект pmt связан с текущим объектом Sale Создан экземпляр dl класса DriverLicense, при этом dl.number=driversLicenseNum Объект dl связан с объектом pmt Создан экземпляр cpr класса CheckPaymentRequest Объект pmt связан с объектом cpr Объект cpr связан с объектом CheckAutorizationService

Описание операции handleCheckReply

	Описание
Имя	handleCreditReply (reply:CheckPaymentReply)
Обязанности	Обработать ответ службы авторизации чеков. Если получено подтверждение, то завершить продажу.
Тип (класс)	Системная
Примечания	Объект reply представляет собой запись, которая должна быть преобразована в объект CheckPaymentApprovalReply или CheckPaymentDenialReply
Вывод
Предусловия	Службе авторизации чеков передается запрос на авторизацию
Постусловия	Если получено подтверждение: Создан экземпляр approval класса CheckPaymentApprovalReply Объект Sale связан с объектом Store (в журнал регистрации добавлены данные о завершенных продажах) Если получен отказ: Создан экземпляр denial класса CheckPaymentDenialReply

Диаграмма состояний для варианта использования BuyItems приведена на рис. П.16.

Рис. 0.112. Диаграмма состояний для варианта использования BuyItems

Выше приведенно описание только фрагмента процесса разработки.