Связь UML между заказчиком и списком продуктов (программное обеспечение Java Supermaket)

Я пытаюсь создать программное обеспечение для супермаркета, которое позволяет покупателю или владельцу войти в систему и использовать мою систему через графический интерфейс на Java на основе Swing. Когда Клиент вошел в систему, он может просматривать продукты. Когда владелец вошел в систему, он может просматривать продукты и добавлять новые продукты.

Я хочу метод в Customer класс: ViewProducts()
и методы в Owner класс: ViewProducts(), AddProducts().
Эти методы неверны, потому что они не относятся к клиенту / владельцу (они связаны с продуктом).

Мои отношения были бы Customer класс, имеющий отношение 1 к 1 с ProductList и Owner иметь отношения 1 к 1 с ProductList, и два класса могут управлять данными по-своему. Я ошибаюсь?

Этот способ не имеет смысла, потому что Customer а также Owner не может иметь атрибутов, не связанных с ними, например ProductList.

Источник

2 ответа

Решение

Вы всегда должны стремиться запечатлеть то, что существует на самом деле. АCustomerэкземпляр не имеет отношения 1 к 1 сProductList потому что ProductList могут просматривать более одного Customer за один раз, и Customerникоим образом не владеет этим списком.

Что, наверное, ближе к реальности:

  • Каждые Supermarketчеловек управляет однимInventory индивидуальный
  • Каждые Inventory индивидуальный:
    • управляется однимSupermarket индивидуальный
    • включает InventoryItem отдельные лица
  • Каждые InventoryItem индивидуальный
    • состоит из одногоInventory индивидуальный
    • описывает Product отдельные лица
  • Каждые Product индивидуальный
    • описывается однимInventoryItem индивидуальный
    • находится в одномPhysical Location индивидуальный
  • Каждые User Account индивидуальный
    • идентифицирует одно лицо
    • играет роль лиц
  • Каждый человек с ролью предоставляет возможность людям

В реальной жизни люди играют роли. Эти роли могут быть "клиент", "врач" или "полицейский". Каждый человекRoleимеет набор возможностей, которые он может выполнять. В ОО-системе каждый человекRole может использовать операции для реализации своих возможностей, например purchaseProduct(), prescribeMedication(), или writeMovingViolation().

Есть несколько способов представить эти роли и возможности в объектно-ориентированной системе. В одном подходеcustomer экземпляр Role может быть настроен для разрешения доступа к queryInventory() а также purchaseProduct() операции на Supermarket а также InventoryItemклассы соответственно. Anowner экземпляр Role 1 может быть настроен для разрешения доступа кaddInventoryItem() а также removeInventoryItem() операции на Inventory класс.

Вот пример модели UML:

В другом подходе вы можете создать одноэлементные подклассы класса Role класс, называемый CustomerRole а также OwnerRole, а затем каждый из этих подклассов запускает операции. Вы можете положить свойviewProducts() а также addProducts() операции с этими одиночками.

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

Источник

Первое, что вам нужно рассмотреть, это IS-A и HAS-A. Если ваш класс особенный, он должен быть дочерним по отношению к суперклассу. Если в нем что-то есть, то это композиция. Если бы я проектировал это, я бы сделал productList классом, а затем сделал бы сотрудника магазина в качестве суперкласса с владельцем и работником в качестве подклассов, оба брали список продуктов как композицию. Описывает логику проектирования классов.

Источник
Другие вопросы по тегам