Architecture Design

Starting on a new project is very exciting. You start with a brand new problem and have to define the complete hardware and software architecture for the product. This stage presents its own challenges too. It is a big challenge to convert the system requirements into an architecture that will handle the requirements. In this article we will divide the process of architecture design into simple steps.

Architecture design can be de divided into the steps given below:

  1. Analyze the requirements
  2. Define use cases for the system
  3. Identify processors/modules to implement the use cases
  4. Select operating system and hardware platform
  5. Assign requirements to individual processors/modules 
  6. Define sequence diagrams at processor level

Note that architecture design is an iterative process. When you design your architecture you would move through the steps iteratively. For example, after analyzing the requirements and defining the use cases you might find that there are some aspects of the requirements you did not understand. So you would go back to analyzing the requirements.

Analyze the requirements

Entry Criterion Customer requirements are available
Exit Criterion System specifications are reviewed

The first step is to understand the requirements. This appears to be a simple step, you just read the requirements and understand it. But the truth is this could be the most difficult step of the whole process. The reason is that customer requirements may be written in a terse language that may need clarifications from the customer. It is a good idea to document the outcome of this analysis as a specification for the project. Essentially specifications are the customer requirements written in a language your team understands. Often the specifications would have more detail that the original customer requirements. At this stage, getting the system specifications reviewed by the customer will make sure that the customer and you are at the same plane.

Define use cases for the system

Entry Criterion Reviewed system specifications are available
Exit Criterion System level use cases are available

Once the system specification is available, develop system level use cases. The use cases at this level, consider the system to be a monolithic block. All interactions between the users of the system and the system itself are clearly documented. This process can itself be divided to into the following steps:

  1. Identify the entities that will be interacting with the system
  2. Define the interfaces between these entities and the system
  3. Identify the most important scenarios for interactions between the users and the system
  4. Define the use case interactions between the users and system

An Example

Lets consider the example of a digital switching system (telephone exchange) to better understand the steps involved.

  1. Subscribers and other switches are the two entities that will be interacting with a switch.
  2. Subscribers will use the system to setup and receive calls using a standard phone line. Other switches will originate and terminate calls on the switch.
  3. Important scenarios for the system are:
  4. Define each of the scenarios that was identified in step 3. An example is given below. 

Subscriber originates a call (use case)

  1. Subscriber lifts the handset
  2. System gets an origination request
  3. System feeds dial tone
  4. Subscriber hears dial tone
  5. Subscriber dials the digits
  6. Switch removes dial tone
  7. Switch routes the call to another switch by sending origination
  8. etc. etc.

Identify processor/modules to implement the use cases

Entry Criterion Reviewed system use cases are available
Exit Criterion Hardware processor/modules have been identified and basic functionality has been assigned to the processors.

Once you have use cases for major scenarios, you are ready to move to the next step of identifying modules and processors that would be required to handle the system's functionality. Your selection of the hardware components should depend on the level of experience you have in executing similar projects. Here are a few guidelines:

Select operating system and hardware platform

Entry Criterion Processor and modules implementing the system have been decided.
Exit Criterion Hardware and software platforms have been selected.

Selection of the operating system and hardware platform is based on the following factors:

Operating system and hardware platform selections can be very difficult to make. You will find members of your team deeply divided on the selection of the operating system. The best way to introduce some objectivity into decision making might be to consider the factors listed above and assign them weights. Then rate the proposed platform on all these factors.

Assign requirements to individual processors/modules

Entry Criterion Processor and modules implementing the system have been decided and operating system and hardware platform have been selected.
Exit Criterion Complete functionality of the system has been partitioned into different processors. All system specifications have been assigned to processors that constitute the system.

We have identified the modules/processors previously. Once the final hardware and software platform selections have been made, go through the system specifications and assign them to individual modules/processors in the system. A new revision of the system specifications should be produced with these inputs.

Define sequence diagrams at processor level

Entry Criterion System specifications have been partitioned to different processors.
Exit Criterion Processor level sequence diagrams have been produced for all the system use cases.

We consider this to be the final step in architecture design. Here the architects see if the architecture handles all the system level use cases. During this step, system level use cases will give way to processor level sequence diagrams. An example of such a conversion is given below. "Subscriber originates a call" use case is developed into a sequence diagram.

Subscriber originates a call (sequence diagram)

  1. Subscriber lifts the handset
  2. Originating call processor gets an origination request
  3. Originating call processor allocates and assigns a digit collector module.
  4. Originating call processor requests dial tone generator to feed dial tone.
  5. Dial tone generator feeds dial tone
  6. Subscriber hears dial tone
  7. Subscriber dials the digits
  8. Digit collector collects the first digit
  9. Digit collector forwards the first digit to the originating call processor
  10. Originating call processor requests the dial tone generator to disconnect the dial tone.
  11. All other digits are collected in a similar fashion.
  12. Originating call processor obtains routing information from the call routing processor.
  13. Originating call processor communicates with the terminating call processor to further route the call.
  14. etc. etc.

You can see here that the level of detail has increased considerably over the corresponding system level use case.