Which Software Architecture?

There are a variety of software architectures. Each has a particular purpose; several might be considered for a new design. The architectures are not mutually exclusive; for example, you can build a state-machine in an event-driven environment.

Sequential architecture

In this architecture data is seen as moving sequentially from one process to the next, undergoing some transformation by each process. This traditional way of writing programs is still used in many software designs. The primary reasons are:
  1. It works well for classic batch data processing applications.
  2. Most programmers are taught to think sequentially.
  3. Some programming languages don't support other architectures.

State-machine architecture

An application is viewed as being in one of a finite number of well-defined, discrete states, and the applicaiton behavior is essentially transitioning between states. Used extensively in industries where systems are modeled well as state machines. (e.g. process control, telephony). There is an entire industry (process control systems) devoted to providing tools and support for such development.

Applicable Design Pattern: State

Model-View-Controller architecture

The MVC architecture is a fundamental part of the Smalltalk language but can be used by any designer. According to the model, a software application consists of three parts:
  1. Model - the user's application domain
  2. View - a display of the information in the model
  3. Controller - the mechanism that allows the user to change the model
Applicable Design Pattern: Observer
 

Parallel architecture

A parallel application includes two or more tasks (processes) that together comprise the software system. Parallel applications can run on a single computer or a parallel processor.
Good reasons for writing a parallel program.
  1. The system is best modeled as separate processes (e.g. Jukebox)
  2. Maximum performance is important.
  3. The system is too complex for a sequential solution to be possible.
Applicable Design Pattern: Observer
 

Event driven architecture

An application is viewed as a set of components, each of which waits until an event occurs that affects it. An event driven program comprises a set of functions that are called by the environment. (e.g. processLeftButton is called when the user presses the left mouse button)

Modern graphical environments (e.g. Windows, Motif, Presentation Manager) are event driven environments; you have little choice if your platform is one of those.

Real-time systems are also event-driven; events are external interrupts that trigger an appropriate function.

Applicable Design Pattern: State
 

Client-server architecture

There are at least two programs. One, the client, requests information or services from servers. Servers provide services to clients. Generally, the two programs are on different computers but this is not required. Client-server architecture is increasing rapidly in popularity in the 1990s for a variety of reasons:
  1. Customers want open architecture solutions from multiple vendors.
  2. Separation of functionality. (e.g. database and database viewer)
  3. The economy of scale => small computers are cheaper.
  4. The MIS organization can retain control of the servers.
Applicable Design Pattern: Facade
 

Virtual Machine architecture

This architecture treats an application as a program written in a special purpose language.  The system "interprets" the program and produces the appropriate behavior.

Applicable Design Pattern: Interpreter