АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

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

Читайте также:
  1. Cитуация-пример.
  2. II. Примеры, подтверждающие милость, явленную в Пророке, да благословит его Аллах и да приветствует.
  3. Implementing the Design (реализация разработки).
  4. MS Excel.Текстовые функции, примеры использования текстовых функций.
  5. N-декомпозируемые отношения. Пример декомпозиции. Зависимость проекции/соединения.
  6. Reimplement Design and Verify Pin Locations (Повторная реализация разработки и верификация размещения выводов).
  7. SCADA. Назначение. Возможности. Примеры применения в АСУТП. Основные пакеты.
  8. Tough Enough в качестве примера
  9. XXIV. ПРИМЕР ЗАКХЕЯ
  10. А вот когда мы, к примеру, говорим: «не могу себе позволить пренебрегать своим здоровьем» — это, как говорят дети, «не счетово».
  11. А) Стадия разработки КД (начало инвестиционной фазы)
  12. А.1 Пример расчета решеток с ручной очисткой

Детальное рассмотрение приведенного ниже примера разработки с использованием языка 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.1. Диаграмма вариантов использования в общем виде

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

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


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

В качестве примера рассмотрим описание вариантов использования 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

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

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

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

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

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

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

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

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

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

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

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

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


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.014 сек.)