Попытка создать проект системы, представленный диаграммой классов UML. Потенциально с помощью шаблона адаптера?

Question

Мне нужно описать общий дизайн системы, которая будет обрабатывать различные типы платных звонков и их компонентов, для домашнего задания:

Вы являетесь ведущим разработчиком для компании, которая загнала рынок в угол на платных дорогах. Ваша компания производит простые стенды, где подъезжает транспортное средство, водитель передает деньги плательщику, который записывает транзакцию и дает изменения. Но есть еще много чего платная индустрия. У некоторых платных шлюзов есть ворота, которые открываются и закрываются автоматически или открываются и закрываются вручную плательщиком сборов. Существуют разные типы контроллеров ворот; некоторые, которые идут с ворота, которые открываются и закрываются автоматически (с таймером или без - некоторые используйте датчики движения и препятствия, чтобы определить, когда закрывать ворота). Некоторые контроллеры ворот позволяют использовать разные типы ворот связано. Кроме того, нет никакого стандарта для того, как программное обеспечение для ворот или любых других компонентов в работе системы. То есть, для них нет стандартного интерфейса. Дорожные системы для вашего у клиентов есть свой способ сбора платы за проезд. Некоторые позволят наличные использоваться и вставляться в коллектор монет. Некоторые позволяют кредит карты. Некоторые выдают билеты, когда вы входите в дорожную систему, а затем вы оплатить пошлину при выходе. Сегодня автоматизированные платежные системы, такие как E-Z Проходы используются на большинстве платных дорог, но не на всех. Компания видит продажи платных телефонов стремительно развиваются, и им нужна система программного обеспечения, которая может обрабатывать все возможные изменения, которые существуют сегодня и в Будущее без переписывания кода. Это было дано вам как ведущий разработчик / архитектор в компании.

Я знаю, что есть разные типы ворот, платежные механизмы, некоторые датчики и другие вещи, которые упоминались выше. Я также пытаюсь учесть различия, которые клиент может внести при заказе своих сборов у «этой компании».

Я создаю диаграмму классов UML, которая показывает ключевые компоненты и как они связаны друг с другом, но я не уверен насчет дизайна для использования. Я думаю, что шаблон адаптера будет хорошим выбором для этого? Это звучит правильно?

Я создал базовые начальные классы, такие как Client, Tollbooth и Gate. И я знаю, что Client знает о Tollbooth, а Tollbooth знает о Gate, но я, как поступить, когда дело доходит до интерфейсов и конкретных методов?

Answer 1

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

Высокий обзор подхода заключается в переформулированииТребования, чтобы подчеркнуть технические аспекты.

1-й старт, пропустив детали, такие как There are different types of gate controllers; some that come with gates that open and close automatically... и обратите внимание на общую точку зрения

• обработать ручку
• (открыть /закрыть) ворота

оба могут рассматриваться как поведение

2-й шаг, постепенно добавлять детали

• обработать платеж

  • вручную: оператор берет деньги, записывает транзакцию, возвращает изменение
  • автоматически: система считывает кредитную карту, списывает сумму, записывает транзакцию
  • тикет:система выдает тикет и через некоторое время (когда драйвер достигает существующего) транзакция обрабатывается

• обрабатывает ворота

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

На втором этапе легко заметить, что может бытьразличные реализации поведения, определенные на 1-м шаге.На 2-м шаге можно заметить некоторые другие поведения

• сигнализировать об открытии
• сигнализировать о закрытии
  • с использованием таймера
  • с использованием датчика движения
  • с помощью датчика препятствий

продолжайте добавлять детали и проверяйте новое поведение, пока все детали не будут исчерпаны

3-й шаг идентифицирует модель(с подробной информацией), участвующей в системе

• Оплата: содержит сумму и дату платежа
• Ворота: содержит состояние ворот (открыт / закрыт) * ​​1065 *
• Сигнал: Открыть / Закрыть
• ...

4-й шаг идентифицировать действия

• TransactionProcessor: получает детали для платежа и обрабатывает их
• Датчик: генерирует сигналы, такие как сигнал закрытия затвора.
• GateController: обрабатывает сигналы от платежного процессора или от датчика
• ...

5thпошагово сложите модель и действия

• start (запущеныоператором с кассового автомата или терминала кредитной карты или ...)
• построить Payment объект
• и отправить его на TransactionProcessor
• иTransactionProcessor обрабатывает транзакцию с деталями из объекта Payment и возвращает детали транзакции (статус ok / nok)
• , и если транзакция в порядке, создайте Signal, чтобы открыть ворота
• и отправить его на GateController
• , а GateController открывает Gate
• и ожидает закрытия Signal
• иSensor генерирует закрытие Signal
• , а GateController закрывает Gate

Обратите внимание, что на 5-м шаге нет подробностей о том, как обрабатываются транзакции, икак генерируются сигналы, так как это детали реализации.На этом шаге абстракции (например, в Java интерфейсы) должны быть уточнены

6-й шаг добавить детали реализации (реализации для абстракций, определенных на 5-м шаге)

• как обрабатывается платеж вручную
• как обрабатывается платеж кредитной картой
• как генерируется сигнал закрытия (на основе датчика или таймера или ...)
• ...

Поскольку поведение

• обрабатывает платеж (стратегия с различными реализациями)
  • вручную с помощью контрольно-кассовой машины
  • автоматически с помощью кредитной карты
  • по билетам
• обрабатывать ворота (стратегия с различными реализациями)
  • вручную
  • автоматически с датчиком движения
  • автоматически с датчиком обструкции
  • автоматически с таймаутом

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

• Стратегия может быть полезна для реализации вышеуказанного поведения
• Команда может быть полезно для реализации открывающих / закрывающих ворот

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

Такое решение может быть легко расширено при необходимости с помощью новых реализаций для существующего поведения (таких различных способов обработки гейтва или различных способов обработки платежа или новых датчиков, которые будут использоваться), не затрагиваясуществующие

Answer 2

Какова цель?

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

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

Что является ключом к ожидаемому дизайну?

Повествование объясняет это довольно хорошо:

(...) нет никакого стандарта для того, как программное обеспечениедля ворот или любых других компонентов в работе системы.То есть для них не существует стандартного интерфейса .

Мы понимаем, что конфигурация стенда может существенно различаться:

• по крайней мере, контроллер шлюза, который контролирует один или два шлюза, платежную систему и один датчик.
• Платежная система может быть человеком, управляющим ручным управлением, или полностью автоматизированной платежной системой (или обеими, если кредитная карта заблокирована в считывателе).
• Контроллер ворот может взаимодействовать с одним или несколькими датчиками и таймерами.
• Автоматическая платежная система, если она имеется, может взаимодействовать с различными билетными и платежными устройствами.Он также может взаимодействовать с датчиками.

Таким образом, ключевым является создание системы, которая позволяет различным компонентам работать вместе, используя хорошо известный интерфейс.

Шаблоны проектирования?

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

К счастью, здесь на ум приходят два шаблона проектирования:

• Шаблон проектирования помогает при посредничестве между платежной системой,контроллер шлюза и различные таймеры и датчики, которые будут иметь один и тот же коллега интерфейс.
• Составные шаблоны составного помогают, позволяя иметь компоненты, которые могут быть сделаны из переменного числа подкомпонентов.

Есть ли лучший выбор?

Я не знаю, насколько реалистичным должен быть ваш домашний дизайн, каков ваш уровень знаний:

• Вы можете выбрать упрощенный дизайн, который определяет основные компоненты конфигурации, каждый из которых предоставляет гипотетический интерфейс (абстрактный класс), специфичный для их вида (например, Sensor), который позволяет специализировать конкретные классы (например, MotionSensor).).Если вы на начальном уровне, выберите этот.
• Вы можете выбрать очень плоскую структуру, используя только медиатор.Это принцип программной шины.Каждый компонент должен был бы удовлетворять общему интерфейсу, но каждый компонент должен был бы общаться через посредника, понимая, что может быть другой адаптер, чтобы адаптировать различные типы компонентов к требованиям посредника.Если вы на промежуточном уровне, это кандидат.
• Вы можете выбрать смешанный подход, при котором посредник обеспечивает связь между основными компонентами, и каждый компонент может быть настраиваемым композитом.Это очень прагматичный, но расширяемый подход.Если вы на среднем уровне, это тоже кандидат.
• Вы можете выбрать композит, где каждый компонент будет выступать в качестве специализированного посредника для своих подкомпонентов.Это довольно сложно.Но через 20 лет этот дизайн может соответствовать потребностям (например, когда вы подключите интеллектуальную систему распознавания лиц).Выберите это, только если вы на продвинутом уровне.