Large systems can be decomposed into sub-systems that provide some related set of services. The initial design process of identifying this sub system and establishing a framework for sub-system control and communication is called Archltectunt design in software engineering.
The architectural design comes before detailed system specification, it should not include any design information. Architectural design is necessary to structure and organize the specification. This model is the starting point for the specification of the various parts of the system.
There is no generally accepted process model for architectural design. The process depends on application knowledge and the skill and intuition of the system architect. For the process, the following activities are usually necessary:
- The system is structured into several principal sub-systems where a sub-system is an independent software unit. Communications between sub-systems are identified.
- Control modeling: A general model of the control relationships between the parts of the system is established.
- Modular decomposition: Each identified sub-system is decomposed into modules. The architect must decide on the types of the module and their interconnections.
During any of these process stages, it may be necessary to develop the design in more detail to find out if the architectural design decision allows the system to meet its requirements. The output of the architectural design process is an architectural design document. This consists of several graphical representations of the system models along with the associated descriptive text. It should describe how the system is structured into sub systems and how each sub-system is structured into modules.
The first phase of the architectural design activity is usually concerned with decomposing a system into a set of interacting sub-systems. At its most abstract level, an architectural design may be depicted as a block diagram in which each box represents a sub-system. Boxes within boxes indicate that the sub-system has itself been decomposed into sub-systems. Arrows mean that data and/or control is passed from the sub-system in the direction of the arrows. This is illustrated in the given figure.
The figure shows an architectural design for a packing robot system. This robotic system can pack different kinds of objects. It uses a vision sub system to pick out objects on a conveyor, identifies the type of object, and selects the right kind of packaging from a range of possibilities. It then moves objects from the delivery conveyor to be packaged. Packaged objects are placed on another conveyor.
More specific models of the structure may be developed which show how sub-systems share data, how they are distributed, and how they interface with each other. In this section three of these standard models, namely a repository model, a client-server model, and an abstract machine model are discussed.
The repository model
Sub-systems making up a system must exchange information so that they can. work together effectively. There are two ways in which this can be done:
- 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.
- Each sub-system maintains its database. Data is interchanged with other sub-systems by passing messages to them
The majority of systems, which use large amounts of data, are organized around a shared database or repository. This model is therefore suited to applications where data is generated by one sub-system and used by another.
The figure shown above is an example of a CASE toolset architecture based on a shared repository.
The advantages and disadvantages of a shared repository are as follows:
- It is an efficient way to share large amounts of data. There is no need to transmit data explicitly from one sub-system to another.
- Sub-systems must agree on the repository data model. Inevitably, this is a compromise between the specific needs of each tool. Performance may be adversely affected by this compromise. It may be difficult or impossible to integrate new sub-systems if their data models do not fit the agreed schema.
- Sub-systems, which produce data, need not be concerned with how that data is used by other sub-systems.
- Evolution may be difficult as a large volume of information is generated according to an agreed data model. Translating this to a new model will certainly be expensive and may be difficult or even impossible.
- Activities such as backup, security, access control, and recovery from error are centralized. They are the responsibility of the repository manager. Tools can focus on their principal function rather than be concerned with these issues.
- Different sub-systems may have different requirements for security, recovery, and backup policies. The repository model forces the same policy on all sub-systems.
- The model of sharing is visible through the repository schema. It is straightforward to integrate new tools given that they are compatible with the agreed data model.
- It may be difficult to distribute the repository over several machines. Although it is possible to distribute a logically centralized repository, there may be problems with data redundancy and inconsistency.
The client-server model
The client-server architectural model is a distributed system model which shows how data and processing are distributed across a range of processors as shown in the given figure. The major components of this model are:
- A set of stand-alone servers which offer services to other sub-systems. Examples of servers are print servers which offer printing services, file servers which offer file management services, and a compile server which offers language translation services.
- A set of clients that call on the services offered by servers. These are normally sub-systems in their own right. There may be several instances of a client program executing concurrently.
- A network that allows the clients to access these services. In principle, this is not necessary as both the clients and the servers could run on a single machine. Clients must know the names of the available servers and the services that they provide. However, servers need not know either the identity of clients or how many clients there are. Clients access the services provided by a server through remote procedure calls.
The client-server approach can be used to implement a repository-bad system where the repositol}' is provided as a system server. Sub-systems accessing the repository are clients. Normally, however, each sub-system manages its data. Servers and clients exchange data for processing. This can result in performance problems when large amounts of data are exchanged. However, as faster networks are developed, this problem is becoming less significant.
The most important advantage of the client-server model is that distribution is straightforward. Effective use can be made of networked systems with many distributed processors. It is easy to add a new server and integrate it gradually with the rest of the system or to upgrade servers transparently without affecting other parts of the system
The abstract machine mode
The abstract machine model of architecture (sometimes called the layered model) models the interfacing of sub-systems. It organizes a system into a series of layers each of which provides a set of services. Each layer defines an abstract machine whose machine language (the services provided by the layer) is used to implement the next level of the abstract machine. For example, a common way to implement a language is to define an ideal 'language machine' and compile the language into code for this machine. A further translation step then converts this abstract machine code to real machine code.
A well-known example of this approach is the OSI reference model of 1etwork Protocols. Another influential example of this approach was proposed by suggesting a three-layer model for an Ada programming support environment (APSE).
The given above figure shows that the version management system relies on 11anaging versions of objects and provides general configuration management facilities. To support this configuration management facility, it uses an object management system that provides information storage and management services for objects. This system uses a database system to provide basic data storage and services such as transaction management, rollback and recovery, and access control. The database management uses the underlying operating system facilities and files stored in its management use the underlying operating system facilities and files stored in its implementation.
The layered approach supports the incremental development of the system. As a layer is developed, some of the services provided by that layer may be made available to users. This architecture is also changeable and portable.
A disadvantage of the layered approach is that structuring a system in this way can be difficult. Inner layers may provide basic facilities, such as file management, which are required by all abstract machines. Services required by the user may therefore require access to an abstract machine that is several levels beneath the outermost layer. This subverts the model, as an outer layer is no longer simply dependent on its immediate predecessor.
Performance can also be a problem because of the multiple levels of command interpretation, which are required. If there are many layers, some overhead is always associated with layer management. To avoid these problems, applications may have to communicate directly with inner layers rather than use facilities provided in the abstract machine.