Architectural design

Chapter 11

Architectural design is the initial design process of identifying sub-systems and establishing a framework for sub-system control and communication. Using large-grain components improves performance, and using fine-grain components improves maintainability, so if both of these are important system requirements developers should find some compromise solution. There is an overlap between the process of requirements engineering and architectural design.

Sub-system design is an abstract decomposition of a system into large-grain components, each of which may be a substantial system in its own right. Block diagrams are often used to describe sub-system designs where each box in the diagram represents sub-system. Sub-systems can have their own sub-systems, in that case boxes are placed into boxes. Arrows mean that data and or control signals are passed from sub-system to sub-system in the direction of the arrows.

Architectural design is a creative process so many decisions are being made depending on requirements, specific rules for particular project and experience of an architect. Architectural models that may be developed may include:

• A static structural model that shows the sub-systems or components that are to be developed as separate units.
• A dynamic process model that shows how the system is organised into processes at run-time.
• An interface model that defines the services offered by each sub-system through its public interface.
• Relationship model that shows relationships, such as data flow, between the sub-systems.
• A distributed model that shows how sub-systems may be distributed across computers.

Different models may be used. Sub-systems making up a system exchange information so that they can work together effectively. There are two fundamental ways in which this can be done.

1. All shared data is held in a central database that can be accessed by all sub-systems. A system model based on a shared database is sometimes called a repository model.
2. Each sub-system maintains its own database. Data is interchanged with other sub-systems by passing messages to them.

The majority of systems that use large amount of data are organised around a shared database or repository. This model is suited to applications where data is generated by one sub-system and used by another.

The client-server architectural model is a system model where the system is organised as a set of services and associated servers and clients that access and use the services. Clients may have to know the names of the available servers and the services that they provide.

The layered model of an architecture (sometimes called an abstract machine model) organises a system into layers, each of which provide a set of services. Each layer can be thought of as an abstract machine whose machine language is defined by the services provided by the layer. This ‘language’ is used to implement the next level. This approach supports the incremental development of systems.

After an overall system organisation has been chosen, different approaches may be used to decompose sub-systems into modules. Two main strategies of doing this are:

1. Object-oriented decomposition where a system is decomposed into a set of communicating objects. Object call on the services offered by other objects. The object-oriented approach is well-known and convenient, but still has some disadvantages, for example, to use services, objects must explicitly reference the name and the interface of other objects. If an interface change is required to satisfy proposed system changes, the effect of that change on all users of the changed object must be evaluated.
2. Function-oriented pipelining where the system is decomposed into functional modules that accept input data and transformed into output data. Each processing step is implemented as a transform.

The models for structuring a system are concerned with how a system is decomposed into sub-systems. To work as a system, sub-systems must be controlled so that their services are delivered to the right place at the right time. There are two generic control styles that are used in software systems:

• Centralised control. One sub-system has overall responsibility for control and starts and stops other sub-systems. It may also devolve control to another sub-system bit will expect to have this control responsibly returned to it.
• Even-based control. Rather than control information being embedded in a sub-system, each sub-system can respond to externally generated events. These events might come from other sub-systems or from the environment of the system.