-1

I need to describe a general design for a system that will handle the different types of tollbooths and their components, for a homework question:

You’re the lead developer for a company that has cornered the market on high-way tollbooths. Your company produces simple booths where a vehicle drives up, the driver hands money to the toll taker who records a transaction and gives change. But there is so much more to the tollbooth industry. Some tollbooths have gates that open and close automatically, or are opened and closed manually by the toll taker. There are different types of gate controllers; some that come with gates that open and close automatically (with or without a timer—some use motion sensors and obstruction sensors to determine when to close the gate). Some gate controllers allow different types of gates to be connected. On top of this, there is no standard for how the software for the gates, or any other components in the system work. That is, there is no standard interface for them. The road systems for your customers have their own way of collecting tolls. Some will allow cash to be used and inserted into a coin collector. Some allow credit cards. Some issue tickets when you enter the road system and then you pay the toll when you exit. Today, automated payment systems like E-Z Pass are used on most toll roads, but not all. The company sees the sales of tollbooths booming and wants a software system that can handle all of the possible variability that exists today and in the future without a lot of rewriting code. This has been given to you as the lead developer/architect in the company.

I know that there are different types of gates, payment mechanisms, some sensors, and other things that are mentioned above. I'm also trying to account for variations that the customer can make when ordering their tollbooths from "this company".

I'm creating an UML class diagram that shows the key components and how they relate to each other, but I am unsure about the design to use. I think the adapter pattern would be a good choice for this? Does that sound right?

I've created the basic starting classes like Client, Tollbooth, and Gate. And I know the Client knows about the Tollbooth and the Tollbooth knows about the Gate, but I'm how to proceed when it comes to interfaces and specific methods?

Christophe
  • 68,716
  • 7
  • 72
  • 138
Hello
  • 219
  • 2
  • 7
  • Wow, that's a pretty big job. What exactly do you want to know? To be honest, taking the question as-read, this is the sort of thing that would take days of analysis just to find out enough about the domain to start the architecture process. There are so many assumptions you'd need to clarify. Adapter pattern? Maybe, but there's much more to this to figure out before you get to that level? – muszeo Apr 07 '19 at 04:52
  • If the intent from your lecturer/tutor/professor is that this is a simple homework task, then you will have to start by defining terms and your scope. Document what you're assuming to be true or false, and what your constraints are. For example, that your software won't do credit card processing but hand that off to something else; the function of gates is logically the same, hence you can use adapter for the controllers and so on. – muszeo Apr 07 '19 at 04:58

1 Answers1

0

Following is an example of an approach to find a suitable technical solution (with design patterns) rather than an attempt to design a complete solution for given requirements.

The high overview of the approach is to reformulate the requirements to emphasis the technical aspects.

1st start by skipping the details like There are different types of gate controllers; some that come with gates that open and close automatically... and notice the common ground

  • process a payment
  • handle (open/close) a gate

both could be seen as behaviors

2nd step, incrementally add details

  • process a payment

    • manually: an operator takes the money, records the transaction, returns change
    • automatically: the system reads a credit card, charges the amount, records the transaction
    • ticketing: the system issues a ticket and after a while (when the driver reaches the exist) a transaction is processed

  • handle the gate

    • manual gate controller: simply do nothing, an operator handles the gate
    • automated gate controller: on a signal open the gate, on a second signal close the gate. The first signal should come from the transaction processor the second signal could come from a timer or a motion sensor or an obstruction sensor

From the 2nd step is easy noticeable which could be different implementations for the behaviors identified in the 1st step. In the 2nd step some other behaviors could be noticed

  • signal the open
  • signal the close
    • using a timer
    • using a motion sensor
    • using an obstruction sensor

keep adding details and check for new behaviors until all the details are exhausted

3rd step identify the model (with details) involved in the system

  • Payment: holds the amount and the payment date
  • Gate: holds the state of the gate (opened/closed)
  • Signal: Open/Close
  • ...

4th step identify the actions

  • TransactionProcessor: receives details for a payment and processes them
  • Sensor: generates signals like close the gate signal
  • GateController: processes signals from a payment processor or from a sensor
  • ...

5th step put together the model and the actions

  • start (triggered by an operator from a checkout machine or a credit card terminal or ...)
  • build the Payment object
  • and send it to the TransactionProcessor
  • and the TransactionProcessor processes the transaction with the details from the Payment object and returns the details of the transaction (status ok/nok)
  • and if transaction is ok build the Signal to open the gate
  • and send it to the GateController
  • and the GateController opens the Gate
  • and waits for the close Signal
  • and the Sensor generates the close Signal
  • and the GateController closes the Gate

Notice in 5th step there are no details about how the transactions are processed nor how signals are generated, as these are implementation details. In this step the abstractions (e.g. in Java the interfaces) should be refined

6th step add implementation details (implementations for the abstractions defined in the 5th step)

  • how the manual payment is processed
  • how credit card payment is processed
  • how close signal is generated (based on a sensor or a timer or ...)
  • ...

Since behaviors

  • process a payment (a strategy with different implementations)
    • manually with a checkout machine
    • automatically with a credit card
    • by tickets
  • handle a gate (a strategy with different implementations)
    • manually
    • automatically with motion sensor
    • automatically with obstruction sensor
    • automatically with timeout

need to be modeled check the list of behavioral design patterns.

  • Strategy could be useful for implementing the above behaviors
  • Command could be useful for implementing the open/close gate

Other useful design panther (non behavioral) could be Observer for implementing the gates with sensors (observe a sensor and handle the gate)

Such a solution could easily be extended when needed with new implementations for the existing behaviors (such different ways to handle the gate or different ways to handle the payment or new sensors to be used) without affecting the existing ones