 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Вычисление общей стоимости покупки
Согласно паттерну Expert отвечать за вычисление общей стоимости продажи должен сам класс Sale, поскольку он обладает информацией обо всех экземплярах SalesLineItem, стоимость которых суммируется при вычислении общей стоимости. Вычисление общей стоимости реализовано в виде операции total.
Для вычисления общей стоимости покупки Sale необходимо знать стоимость каждого покупаемого товара SalesLineItem. Согласно паттерну Expert за это отвечает сам класс SalesLineItem, так как ему известно количество покупаемых единиц товара и спецификация этого товара. Данная обязанность реализована в виде операции subtotal.
Для вычисления стоимости каждого товара SalesLineItem необходимо знать цену товара со спецификацией ProductSpecification. Согласно паттерну Expert за это отвечает класс ProductSpecification, так как он хранит всю необходимую информацию. Данная обязанность реализована в виде операции price.
Диаграмма кооперации для операции total представлена на рис. П.7.
Рис. П.0.7. Диаграмма кооперации для операции 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.8. Диаграмма кооперации для системной операции makePayment
Сведения о приобретенных покупках должны заноситься в журнал регистрации. Согласно паттерну Expert, всей необходимой информацией обладает объект Store, поскольку он связан с финансовой деятельностью предприятия.
Диаграмма кооперации для регистрации покупки приведена на рис. П.9.
Рис. П.0.9. Диаграмма кооперации для регистрации покупки
Для реализации процесса вычисления причитающейся сдачи необходимо разработать соответствующую диаграмму кооперации.
Для вычисления баланса необходимо знать общую стоимость покупки и внесенную покупателем сумму. Согласно паттерну Expert при решении этой проблемы в качестве эксперта должны выступать классы Sale и Payment. Если основная обязанность по вычислению баланса возлагается на класс Payment, то для него необходимо обеспечить видимость класса Sale, от которого необходимо получить общую стоимость покупки. Это приведет к увеличению уровня сцепления.
Если основная обязанность по вычислению баланса возлагается на класс Sale, то для него необходимо обеспечить видимость класса Payment, от которого необходимо получить внесенную покупателем сумму. Так как класс Sale является создателем экземпляров Payment, такая видимость уже обеспечена и данный подход не приведет к увеличению уровня сцепления. Поэтому этот подход предпочтительнее.
Диаграмма представлена на рис. П.10.
Рис.П.0.10. Диаграмма кооперации вычисления баланса
Описание операции 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.11. Диаграмма создания исходного специального объекта и последующих объектов
Диаграмма классов
В ходе анализа концептуальной модели и диаграмм взаимодействия строится диаграмма классов. Для системы розничной торговли диаграмма классов представлена на рис. П.12.
Рис.П.0.12. Диаграмма классов
КОНСТРУИРОВАНИЕ (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 (Оплата чеком)
Поиск по сайту: