Coupon Accepted Successfully!


Architectural Engineering and Design


The design activity is the bridge between the software requirements and analysis models, and deliverable product construction.  Design is the process of producing the “blueprint” for the coding and testing.  It is also the activity which establishes software quality.  The results of design activities are representations which can be assessed for quality.  The list of frequently cited software quality attributes is sometimes called FRUPS, an acronym for the following list:

  • Functionality
  • Reliability
  • Usability
  • Performance
  • Supportability


There is a huge difference between simply getting code to work and engineering a system of high quality. The following design concepts have been helpful in achieving software quality:




When developing an architectural design of a complex system, many levels of abstraction are needed to describe the system.  Higher levels contain fewer details and lower levels provide increasingly more system information.  Procedural abstractions contain instructions but suppress details.  Data abstractions refer to data objects and their properties.




When dealing with complexity, cognitive psychologists tell us that we humans can deal with only from five to nine chunks of information at a time.  Therefore, the strategy of designing a system as a collection of integrated modules is necessary for system understanding.


Information Hiding


Many architectural designs are possible for a given project.  How does one assess the quality of a given system modularization?  Application of the principle of information hiding in the development a modularization is known to increase quality as defined by the FRUPS attributes.  The idea is to define module boundaries so that local information is encapsulated and hidden from its outside world.  Module interfaces are designed to communicate only information that is essential to invoking the functionality of the module.  Careful application of this principle pays large dividends during the testing and maintenance phases of the life of the system. 


Functional Independence


Modules that are designed to be functionally independent and have simple interfaces with the remaining system are known to be easier to develop, test and maintain.  Two criteria for assessing independence are cohesion and coupling, measures of singleness of function and intermodule connectivity, respectively. High cohesion and low coupling contribute to higher quality.




The design process is sometimes called a top-down step-wise refinement of the top level system abstraction to successive lower levels of abstraction by the application of the above modularization principles. Modules are created by hierarchical decomposition.



This activity is usually specific to agile methods.  It refers to the internal redesign or restructuring of a component or subsystem in ways that improve its quality and performance.


Design and Reuse of Patterns

As with other more mature engineering disciplines, one should always approach design decisions with the mindset that design patterns used in the past should be considered first rather than proceeding with a design derived from the uniqueness of the requirements of the particular project.  If patterns of the past do not seem to be suitable, creating new ones should be the next level of consideration and contributing to the pattern library for the use of future projects.  Design patterns range from the architectural level down to component detail design.


Component Level Design

This level of design describes the data structures, interfaces and algorithms.  Component level design can be represented in a programming language, but is also often described in some other intermediate representation such as a program design language (PDL) for conventional module design and the Object Constraint Language (OCL) in the object-oriented design world.


User Interface Design


A common failure of software projects is to spend too little time communicating with the user.  It is easy for software experts to fall into the subconscious trap of “knowing what is good for the user”.  What may seem to be “clearly good for the user” is all too frequently not the case from the perspective of the user herself.  The use of user scenarios and very early and iterative prototype screen designs can help to assure that the user is being understood.  It has been said that you should plan on building one to throw away.  Three good guidelines are the following:

  • Put the user in control
  • Reduce the user’s memory load
  • Make the interface consistent


Test Your Skills Now!
Take a Quiz now
Reviewer Name