Отношения UML между клиентом и списком продуктов (Java Supermaket Software) - PullRequest
Новая
       20

Отношения UML между клиентом и списком продуктов (Java Supermaket Software)

0 голосов
/ 12 января 2020

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

Мне нужен метод в классе Customer: ViewProducts()
и методы в классе Owner: ViewProducts() , AddProducts().
Являются ли эти методы неправильными, поскольку они не указаны c для клиента / владельца (они связаны с продуктом).

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

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

Ответы [ 2 ]

2 голосов
/ 12 января 2020

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

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

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

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

Существует несколько способов представления этих ролей и возможностей в ОО система. В одном подходе экземпляр customer Role может быть сконфигурирован для предоставления доступа к операциям queryInventory() и purchaseProduct() в классах Supermarket и InventoryItem соответственно. owner экземпляр Role 1 может быть настроен для предоставления доступа к операциям addInventoryItem() и removeInventoryItem() в классе Inventory.

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

enter image description here

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

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

0 голосов
/ 12 января 2020

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

...