SOFTWARE IN PRACTICE
(Alias: System Architecture, Software Architecture, Hardware Architecture, Architecture Views)
We are now ready to come to grips with the most basic problem of a building or a town: what is it made of? What is its structure, what is its physical essence? What are the building blocks of which its space is made?
In the context of software and electronic systems an architecture is a particular arrangement of various hardware and software components that makes up a unique system. All systems are designed to achieve some human purpose: The web application Facebook connects people in a social network, an aircraft transports people long distances. A Boeing spokesman once quipped, "We view a 777 airliner as a collection of parts flying in close proximity." The job of a systems architect is to manage the design of these complex systems, and systems of systems such as the 777, to make sure that when put into service a particular system fits its assigned purpose and that none of its parts "break formation" to cause harm to people or property. Architectural descriptions deal with complexity by decomposing systems into design entities such as sub-systems and components. Architectural blueprints describe this decomposition in terms of physical and logical structures, their components, their interfaces and the mechanisms they use to communicate both internally and with external systems and human beings.
Figure 1. An Example of a Physical System Architecture
Describing an Architecture
Architectural structures are described in terms of:
Figure 2. A Logical Architecture for an Air Traffic Control System
The latest thinking in architecture descriptions recommends the concept of architectural design views. Views describe a system from the viewpoint of different stakeholders such as end-users, developers and project managers. Philippe Kruchten [Kruchten 95] describes an architecture for software intensive systems called "the 4+1 Architectural View Model". It is based on the use of multiple, concurrent views. Other examples of view based architectural descriptions can be found in:
Describing the Nonfunctional Characteristics of the Architecture
An architecture description also indicates how non functional requirements will be satisfied. For example:
Why Architecture Descriptions are Important
A detailed and on-going consideration of architecture is necessary as we build larger, more complex and more life critical systems involving both hardware and software. An architecture description is the most important artifact for achieving design understanding in a development team. It is also a thinking document performing high-level analysis and providing a vehicle for validating the architectural design and identifying any design deficiencies.
To fulfill its role in the design effort an architecture must be formally documented. Figure 3 depicts a typical documentation tree for a large software and electronic system and highlights the relationships of architectural descriptions to other product specifications. The architecture is first described in a System Architecture Specification (SyAS). The SyAS allocates system level requirements to hardware and software components. These requirements are fleshed out further in Hardware and Software Requirements Specifications. The hardware and software architectures are then described in Hardware Architecture Design Descriptions (HADDs) and Software Architecture Design Descriptions (SADDs).
A pure software product is described with a Software Architecture Design Description.
Figure 3. Architecture Descriptions in the Project Documentation Tree