Example - ATM

The ATM is a classic example in software engineering. Here, it is used to examplify requirements formalization and architecure centric development.

Disclaimer: I have never built an ATM. It may very well be that I have completely missed important requirements. Maybe the software must be based around a transaction engine. I don't know. Despite this, I think the example serves as a good introduction to requirements formalization and architecture centric development.

Without going into the specific requirements for ATM software, it is possible to imagine the major groups of requirements that are important.

• User interaction sequence.
• Bank communication protocol.
• ATM physical hardware interaction.

The first thing we should focus on is the formalization of as many requirements as possible.

The bank communication protocol is a good candidate to be formalized. There exists several protocol definition languages, where ASN.1 is one of them. This formalization results in a component, 'WireProtocol.def'.

The user interaction sequence should also be possible to formalize. We need states, transitions, events and timeouts to describe the interaction sequence and the flow of information within the system. This should be expressed in some existing language, but if none can be found, we will have to define our own. This formalization results in a component, 'Workflow.def'.

This time we don't need to do any more formalization work, as the hardware interaction already is defined with third party libraries.

From this work, we can propose an initial architecture for the ATM software.

It is easy to understand that the central component in the ATM software containts a lot of code and manages lots of information. This will make it difficult to implement and test. The implementation work is also difficult to coordinate between a large number of developers. We need to split the system component up in smaller, reusable and tesable components.

If we separate the user interface from the core application, we make it easier to automatically test the application.

The Bank protocol is a good domain for a component. If we can take advantage of a standard protocol encoder/decoder for our protocol definition file as well, it will be great.

The workflow definition should be handled with a generic workflow engine. Chances are big that we will be able to find an already existing workflow engine to reuse.

These decisions result in the following system architecture.