Моделирование домена или диаграмма классов для автосалона

Question

Я пытаюсь нарисовать модель домена или диаграмму классов в UML для автосалона. Я застрял с тем, как представить тест-драйв в модели. Один из способов состоит в том, чтобы иметь назначенный класс, а затем провести тест-драйв в качестве подкласса. Дилер также предлагает послепродажное обслуживание транспортных средств, чтобы я мог назначить встречу / класс бронирования в качестве суперкласса, а затем обслуживание автомобиля и тест-драйв в качестве двух подклассов.

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

Дилер также продает новые и подержанные автомобили и их запчасти.

Дилер также предлагает финансирование для продажи автомобиля.

Будет ли класс testdrive иметь связь с классом транспортного средства или существует отдельный класс для отображения и класса testdrive?

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

Answer 1

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

Это сообщит, является ли конкретное подклассирование действительно точным.

Я вижу, что встреча может содержать несколько тест-драйвов, которые сами связаны с отдельными транспортными средствами, поэтому сам тест-драйв - это не что иное, как ссылка клиента на автомобиль, связанный с назначением.

Answer 2

Я думаю, вы упускаете суть. Цель доменной модели - познакомить вас с доменом:

-- What kind of entities you have in yor domain?
-- If they are important for your system under desing, 
   what kind of properties they have, how they behave?
-- What kind of business rules they obey?

Остальные детали. Думай как картограф. Запишите, что там есть. Создайте простую карту, чтобы вы не могли заблудиться в этом домене. Не пытайтесь придумывать. Расскажите, что существует в домене. Не бегите за «причудливыми абстракциями», которые вы создали сами.

Доменная модель может быть использована в качестве источника для объектно-ориентированного анализа / дизайна. Но их цель не состоит в том, чтобы представлять программные абстракции.

Answer 3

Вторая часть вашего вопроса была забыта (это легко сделать, если задать два вопроса в одном):

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

Я думаю, что в вашем случае использования есть «Дилер хочет сохранить информацию о потенциальных клиентах, если они позволяют в маркетинговых целях» и самое простое решение - иметь коллекцию списков рассылки, которая содержит имя и адрес каждого потенциального клиента.

Answer 4

тест-драйв будет содержать информацию, относящуюся только к тест-драйву:

ссылка на клиента - даже это может быть спорным, чтобы включить

ссылка на транспортное средство

длина тест-драйва

местоположение (возможно, транспортное средство двигалось в другом месте, чем можно было определить по назначению владельца)

температура клиента (горячая или холодная - т. Е. Потребитель казался восторженным)

комментарии

и т.д.

Но то, что отсутствует в объекте тест-драйва, связано с назначением, поскольку оно всегда содержится в коллекции, возможно, как часть назначения или какого-либо другого контейнера событий. Теперь, если контейнеры, которые могут содержать тест-драйвы, всегда содержат информацию о клиенте, я мог бы даже не включать ссылку на клиента в объект тест-драйва - в конце концов, он будет избыточным.

Зависит от того, могут ли тест-драйвы проводиться в сценариях, не связанных с назначением - возможно, на «мероприятии продаж», «открытом доме» или чем-то, где встречи фактически не создаются в сценариях использования - или если тест-драйвы для нескольких клиенты будут происходить в контейнере.