Architecture Design

Starting on a new project is very exciting. You start with a brand newproblem and have to define the complete hardware and software architecture forthe product. This stage presents its own challenges too. It is a big challengeto convert the system requirements into an architecture that will handle therequirements. In this article we will divide the process of architecture designinto simple steps.
Architecture design can be de divided into the steps given below:
Analyze the requirements
Define use cases for the system
Identify processors/modules to implement the use cases
Select operating system and hardware platform
Assign requirements to individual processors/modules
Define sequence diagrams at processor level
Note that architecture design is an iterative process. When you design yourarchitecture you would move through the steps iteratively. For example, after analyzingthe requirements and defining the use cases you might find that there are someaspects of the requirements you did not understand. So you would go back to analyzingthe 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 asimple step, you just read the requirements and understand it. But the truth isthis could be the most difficult step of the whole process. The reason is thatcustomer requirements may be written in a terse language that may needclarifications from the customer. It is a good idea to document the outcome ofthis analysis as a specification for the project. Essentially specifications arethe customer requirements written in a language your team understands. Often thespecifications would have more detail that the original customer requirements.At this stage, getting the system specifications reviewed by the customer willmake sure that the customer and you are at the same plane.
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. Allinteractions between the users of the system and the system itself are clearlydocumented. This process can itself be divided to into the following steps:
Identify the entities that will be interacting with the system
Define the interfaces between these entities and the system
Identify the most important scenarios for interactions between the users and the system
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.
Subscribers and other switches are the two entities that will be interacting with a switch.
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.
Important scenarios for the system are: Subscriber originates a call (successful, unsuccessful)
Subscriber receives a call (successful, unsuccessful)
Other switch originates a call (successful, unsuccessful)
Other switch terminates a call (successful, unsuccessful)
Define each of the scenarios that was identified in step 3. An example is given below.
Subscriber originates a call (use case)
Subscriber lifts the handset
System gets an origination request
System feeds dial tone
Subscriber hears dial tone
Subscriber dials the digits
Switch removes dial tone
Switch routes the call to another switch by sending origination
etc. etc.
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 tothe next step of identifying modules and processors that would be required tohandle the system's functionality. Your selection of the hardware componentsshould depend on the level of experience you have in executing similar projects.Here are a few guidelines:
If you have an existing system which implements similar functionality, it might be a good idea to reuse the architecture from that project.
If this is a brand new project, consider if the functionality can be implemented by a single processor. A single processor system would be the easiest to implement and debug. (even if you have to provide a 1-for-1 redundant machine).
If the nature of the application or the performance requirements necessitate a multiple processor design, select the minimum number of processors that would be required to implement it. (Keep in mind that adding more processors to your system will complicate both hardware and software development).
In a multiple processor design, separate out the processors that will control and manage the system from the processors that will perform the main operations. It is preferable to have just one processor control and manage the system, thus localizing the complexity of managing the system to a single processor. All other processors in the system handle the real work load of the system.
Design a multiple processor system in such a way that it can scale from a small system to a large one by adding processors. Thus the customer can start with a small number of processors when the system is initially introduced. The system can then grow as the traffic on the system increases.
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 onthe following factors:
Technical merits (performance, stability) of the hardware/software platform
Special requirements from the platform (e.g. does the application require a platform that supports a real-time operating system)
In-house experience with the hardware/software platform
Financial health of the companies backing the hardware/software platform (you don't want to be stuck with a platform from a company that may not be around to support the product)
Company's roadmap for the product (you don't want to select a platform which does not have a clearly defined upgrade path)
Quality of developer tools available for the platform
Cost of training/availability of developers for the platform
Head room in the software/hardware platform to grow with your needs (for example, don't pick a hardware platform when you know that the CPU utilization of the processor will be close to 80%, leaving no room for future growth)
Does the platform require additional in-house development? A completely off-the-shelf platform is going to be a lot cheaper to work with than a in-house designed custom platform.
Availability of device drivers for the platform (Can you afford to develop customer device drivers for every device that will interface with your platform?)
Protocol support in the platform (e.g. does the platform support TCP/IP, HTTP, UDP etc.?)
Operating system and hardware platform selections can be very difficult tomake. You will find members of your team deeply divided on the selection of theoperating system. The best way to introduce some objectivity into decisionmaking might be to consider the factors listed above and assign them weights.Then rate the proposed platform on all these factors.
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/processorspreviously.Once the final hardware and software platform selections have been made, gothrough the system specifications and assign them to individual modules/processorsin the system. A new revision of the system specifications should be producedwith these inputs.
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. Herethe architects see if the architecture handles all the system level use cases.During this step, system level use cases will give way to processor levelsequence diagrams. An example of such a conversion is given below."Subscriber originates a call" use case is developed into a sequencediagram.
Subscriber originates a call (sequence diagram)
Subscriber lifts the handset
Originating call processor gets an origination request
Originating call processor allocates and assigns a digit collector module.
Originating call processor requests dial tone generator to feed dial tone.
Dial tone generator feeds dial tone
Subscriber hears dial tone
Subscriber dials the digits
Digit collector collects the first digit
Digit collector forwards the first digit to the originating call processor
Originating call processor requests the dial tone generator to disconnect the dial tone.
All other digits are collected in a similar fashion.
Originating call processor obtains routing information from the call routing processor.
Originating call processor communicates with the terminating call processor to further route the call.
etc. etc.
You can see here that the level of detail has increased considerably over thecorresponding system level use case.