Figure 1 shows an overview of the software engineering process. The engineering of software is rarely the linear process the diagram might suggest. The final detailed design and implementation are reached through an iterative software design process in which a set of decisions are made that affect the description of the software artefact to be built and its implementation. These decisions are made at different process stages and a decision made at one stage can influence a decision previously made or a decision to be made.

For example, a software design for a set of space telemetry functions, when implemented, may reveal that the planned hardware platform does not have enough memory for the software design to perform efficiently. However, the hardware cannot be changed because it will add extra space and weight to the spacecraft which will affect how much power and fuel are required to launch it and control it in space (in space systems design every millimetre and every microgram counts). If the option does not exist to change the hardware, then the software design must be changed which in turn may affect whether some requirements are changed or eliminated.

The design of a computer-based system’s software architecture is concerned with the overarching structure and behaviour of the system that will satisfy stakeholder expectations and requirements. It’s a representation about the BIG picture, a set of models that focus on the key functions and entities (not all the detail) and how they interact with the outside world and each other. It’s important because it:

provides a focus for communication between different stakeholders

identifies key design decisions

enables design integrity to be maintained as design details are developed

indicates product boundaries

offers a foundation for reuse when many products are to be built.

Over time (i) products change (ii) people forget the detail of what changes were made and how. The keys to software product management success over time are that we ensure:

the latest architectural design is consistent with the original architectural design, and is not a set of disconnected, poorly thought through, ad hoc add-ons

the current architecture and the implementation (the executable code) are consistent with each other

the documentation of the architecture is maintained when changes are made.

The effort and quality put into these activities governs the scope and pace of architectural and product effectiveness or degradation. Many factors affect the effort and quality put into these activities including budget constraints, staff availability, staff capability, evolving desired quality attributes brought about by changing legislation e.g. security, performance, the urgency of stakeholder demands, deployment issues. Then, there comes a point where only a handful of domain experts who have worked on the product a long time really know how it works (e.g. witness 70+ year old contractors who continue to fix 40+ year old legacy COBOL systems).

Key point: Architectural design is not simply a time-bounded process activity that ends with a signed off architectural description when the first version of the product is being built. It is a continuous process throughout the lifecycle of the product.

The starting point for any iterative software design process is to understand the business context into which the software is to be situated and to understand how the software will enhance that business. We want to develop software products that

meet customer expectations (i.e. validation - building the “right product”)

adhere to a set of specified customer requirements (i.e. verification - building the “product right”)

are planned and designed to meet anticipated future requirements (i.e. variability)

enable changes to be made to one part of the system that minimise changes needed to be made to another thus reducing the risk of errors and enhancing productivity (“modularity”)

meet execution performance, security and other quality attribute expectations

anticipate, test for and exit gracefully when there are unexpected hardware failures e.g. power failures, electronic components burning out, water ingress, all of which cause devices to fail.

The requirements for a software product are the description of the services that it should offer and any constraints on their delivery. These requirements reflect the needs of the various stakeholders who will either use the product or be affected by it. A stakeholder can also be another information system or device. The process of discovering, analysing, documenting and sense checking these services and constraints is called Requirements Engineering. This is rarely a straightforward task for many reasons including:

the level of complexity is too much for one person to understand

we often find it difficult to express our requirements with the degree of precision that is needed

we make assumptions in explaining without realising the listener does not have that knowledge

we forget things!

we do not fully understand the motivation and context for building the product

mistakes are made during listening, understanding and documenting.

Consequently, a variety of people, processes, methods, techniques and tools are used to elicit, document, sense-check and cross-check requirements. An output of RE is a Requirements Specification. Requirements can be separated into functional and quality (non-functional) requirements.

Figure 2 shows the different types of requirements and how they map on to the principle software design elements that we saw in Chapter 1 (📷 Figure 1). Functional requirements can be thought of as (i) structural - concerned with the entities within the product (ii) behavioural - concerned with how users interact with the system and how the product interacts with users and other systems. Quality requirements are properties exhibited by the product e.g. performance, security, reliability (see 🔗 https://msdn.microsoft.com/en-gb/library/ee658094.aspx ).

Quality requirements are usually converted into functional requirements within given scenarios. For example, a vague performance requirement about an ATM machine having a satisfactory user response time is converted into a functional requirement stating that the maximum time a user will wait before the system responds to a user request is less than 2 seconds. One way of capturing a set of quality requirements is to develop a set of operational scenarios of the product working, each scenario having its own relative importance value.

Often the requirements of a software product include very specific design and operational constraints. These constraints come from the systems that they are to be a part of, or that they must interact with. This applies particularly to products for which the expected lifetime is likely to be tens of years e.g. cheque ledger systems in banks, aircraft engine management systems, nuclear reactor management systems; or products that must interact with various physical devices which cannot be changed as quickly or cheaply e.g. tool stations and conveyor belts in a warehouse flexible manufacturing system.

The development and shape of good software architecture is underpinned by some key design principles: modularity, information hiding, plan for change, fault tolerance (Table 1). These principles should be upheld regardless of the choices of software engineering processes (e.g. agile, spiral, waterfall), methods (object-oriented, functional, data-driven etc), languages (Java, C, SQL etc), tools (Eclipse, J2EE, Oracle/SAP databases etc) that are deployed. These design principles can be implemented using a range of different design concepts e.g. modularity, inheritance, polymorphism, encapsulation, parameter passing, structured types, composition.

The design challenge is to deploy an appropriate combination of design concepts so that desired quality Quality of Services attributes are satisfied e.g. performance, security, complexity.

Table 1: Key Software Design Principles

Concept	Description
Modularity	A complex problem is better managed if it is arranged into sub-problems that can be solved independently. However too many sub-problems can increase the complexity of the interaction between them. Cohesion is the extent to which different sub-problems fit together. Coupling is the extent to which different sub-problems must communicate with each other. Good design normally has high cohesion and low coupling.
Information Hiding	Information Hiding means only exposing enough detail of a piece of information to enable it to be used, and not exposing information a user does not need to know about (a “need-to-know” basis). For example, we often define an Object with parameters that packages a set of behavioural (procedural) steps or a set of data structures together so that they can be used by referring to the Object name without needing to know the details of how the steps work. The Object is an example of an Abstraction. Other examples of abstractions might be procedures, or tables. The term Refactoring is the process of changing the set of behavioural steps/ data structures to bring enhancements but to the outside world nothing has changed. Good design normally deploys considerable Information Hiding.
Plan for Change	During the lifecycle of a software product, there will be a significant amount of change. Anticipating and planning for change is difficult even when one is guided by a product road map. Architectural change normally takes one of three forms: Local: requiring changes to a single or small group of cohesive components Distributed requiring changes to multiple components in different parts of the system but the underlying structure remains the same Structural: requiring change to the overarching structure of the software affecting most if not all parts of the software Many different mechanisms at different development stages can be used to manage the variability inherent in change e.g. parameters, inheritance, compile time or dynamic link time libraries. However, adding variability usually increases code size and can affect performance, so the cost-benefits always needs careful consideration. The term Variability Management normally refers to the case of planning for change in software product line development when you purposefully set out to develop a set of products to suit different market niches (e.g. mobile phone providers such as Apple or Samsung have a range of mobile products). Each product has common and distinct feature combinations.
Fault Tolerance	Systems can fail either because hardware unexpectedly fails, or the software design has not anticipated a set of events happening. Experienced designers may compromise efficiency to minimise failure risk, particularly in business critical or safety critical scenarios e.g. to avoid single points of failure network designers allow multiple routes for message passing; modern jet aircraft have more than one fly-by-wire system on board in case one fails.

Different design methods, programming languages and development tools provide different levels of support for adhering to these design principles either in design descriptions or in code. In this context a design pattern is a template design description that adheres to the design principles and uses one or more design concepts to provide a solution to a common design problem. For example, a Model-View-Controller design pattern is a template solution for the human-computer interface of a system that involves users frequently interacting with different views of the same data (e.g. financial traders), where the design problem is how to make it easy to change the views without changing the underlying data structures and vice-versa.

Design techniques are tools to help you undertake the design process. The design techniques listed below are commonly used but not an exhaustive list. They are complementary and can be used in any combination that suits your way of thinking and working, as an individual and as a group. They can be used at any time during the architectural or detailed design process. Each one has its advantages in helping to shed light on the solving the problem at hand. Each one also has a cost (time and hence money).

Look to the Past

In generating ideas, most creative tasks consciously or unconsciously draw upon the work of others, and either use them as is or meld them in a different way. Usually others have gone before you trying to tackle the same or similar problems and your starting point is to find out about and draw upon these ideas. This might require taking different approaches. For example, NASA continues to work on how to send manned vehicles to Mars (🔗 https://www.nasa.gov/content/nasas-journey-to-mars). In considering the software architecture for these vehicles, it will take at least three different perspectives. It will look to reuse the software architecture that has been in previous manned vehicles to the moon and the International Space Station, but seek to understand what worked well and what did not. Another approach is to look at the problem from an even higher level of abstraction e.g. to consider the key requirements and design characteristics of any manned vehicle to travel and return from any long-distance space journey. Another approach is to look at the problem from a lower level of abstraction and isolate the novelty e.g. what is going to be the impact of the climatic conditions and terrain on Mars specifically that the vehicle will have to cope with on entry into its atmosphere and on landing.

Diverse thinking

Do not be constrained to drawing ideas from software engineering. Look for ideas from structures, processes, and behaviours from nature, from other industries (industrial automation, construction, fashion, social work, medicine, accountancy, international development) from other fields and disciplines. It is extraordinary how similar abstract structures and behavioural models appear in a variety of different settings. For example, the collaborative and distributed way of working by a colony of ants to achieve a particular goal is finding particular interest in the development of a new generation of self-repairing computer network infrastructures2 .

A complementary approach to tackling architectural design is to recognise that most systems have a range of different stakeholders, that they must interact with one or more existing systems and to consider and model what the system needs to offer from each of these viewpoints. Each of these elements can be documented separately, which makes sense because a practical modelling problem of many systems is that that they are so complex that it is not normally possible to capture the functional features and quality properties in a single comprehensible model that is understandable by anyone.

We define a

A Viewpoint as a perspective on system and its particular needs

A View as a set of design decisions from a particular viewpoint. It can be modelled using a variety of notations and diagrams.

As with Architectural Design in general, one of the main challenges is to get the right content into a view. Provide too much irrelevant detail and stakeholders will be overwhelmed; too little and the risk is that stakeholders get confused or assumptions are made that may not be valid. So ask two key questions: (i) can the stakeholders that it targets use it to determine whether their concerns have been met? (ii) can those stakeholders use it to successfully undertake their role in building the system?

Each system normally also must satisfy a number of different cross-cutting quality attributes e.g. performance, security, reliability. Quality attributes are cross-cutting because they are implemented by a set of different functions throughout the system. Sometimes it can be helpful to also consider these as Viewpoints examine the system under different scenarios from these viewpoints. For example, suppose we were building a multi-biometric recognition system for an airport. The security quality attribute of that system is critical, so we might define Security as a Viewpoint and consider different scenarios such as access to the system itself by several different security staff at the same time, the reliability of the link between the system in the airport and the databases of passports, the performance of the network at peak times etc.

Other commonly captured viewpoints are:

Logical viewpoint: the logical entities in a system and how they are interconnected
Physical viewpoint: the physical entities and how they are interconnected
Deployment Viewpoint: how logical entities are to be mapped onto physical entities
Runtime Viewpoint: the different runtime processes and how they are interconnected

Another categorisation of viewpoints is:

direct viewpoints i.e. people or systems that interact directly with the system

indirect viewpoints i.e. stakeholders who do not use the system themselves but who influence the requirements e.g. sponsors, quality assurance insisting on the adoption of one or more standards

domain viewpoints i.e. significant functional e.g. database integrity or quality requirements e.g. information privacy.

In practice the choice of viewpoints is particular to the architect and the design team based on what they see as important to focus on for the system being constructed. For example, a deployment viewpoint might have special important if the development of the system is to be geographically distributed to different teams in different physical locations, or if the software to written is to be situated on different types of devices with different memory sizes and processing speeds e.g. in an industrial automation plant.

Some issues to be aware of in using views and viewpoints are:

(i) there are often consistency problems in the use of terms and language to refer to the same concept object, particularly when the views are being developed by different people

(iii) there is a temptation is to create a large number of views, so eliminate views that do not address significant concerns for the system you are building

(iii) when you start to represent the same amount of detail in two different views then you have probably produced enough detail.

Focus on Architecturally Significant Requirements

Architecturally significant requirements are those that govern the architecture of the system such that if they are changed there will be a significant impact on all aspects of the architectural and detailed design. Such requirements vary. Deciding whether a specific requirement is architecturally significant is often a matter of judgment and driven by several key factors:

The benefit of the requirement to stakeholders: critical, important, or useful.

The potential scope of the impact on the design: none, extends, or modifies.

Key functional scenarios that affect the interaction of several key data abstractions

The risks to be mitigated: performance, availability of a product, and suitability of a component.

The completion of the coverage of the architecture.

Other tactical objectives or constraints, such as demonstration to the user, and so on.

Good examples of Architecturally Significant Requirements include:

The system must record every modification to customer records for audit purposes.

The system must respond to each user interaction within 5 seconds.

The system must be deployed on both Microsoft Windows 10 and Linux.

The system must encrypt all network traffic.

The system must dispense cash on demand to validated account holders with enough funds.

2 Petra Heijnena, Émile J.L. Chappina and Igor Nikolicb (2014) Infrastructure Network Design with a Multi-Model Approach: Comparing Geometric Graph Theory with an Agent-Based Implementation of an Ant Colony Optimization, Journal of Artificial Societies and Social Simulation 17 (4) 1 <http://jasss.soc.surrey.ac.uk/17/4/1.html

Referring to 📷 Figure 1, in this section we will focus on the process Functionality-based Architectural Design. Section 2.8 will discuss the process Revise Architecture to satisfy Non-functional requirements. The Detailed Design process will the subject of Chapter 4. In practice, to repeat we made earlier, there will also be some iteration between Detailed Design and Functionality-based Architectural Design Some of this is deliberately planned and some of this is emergent as unexpected issues arise.

Overview

Architectural Design considers three principal sources of information that are each unique to the system environment:

i. the context and characteristics of the application domain i.e. understanding the problem to solved, who will it help, why will it help them, who is sponsoring it, what legacy systems exist already, what will it interface with etc, where and how is it to be deployed.

ii. the outputs of the requirements engineering process e.g. requirements expressed in natural language or models e.g. context models, interaction models, structural models, behavioural models

iii. the experience and knowledge of the architect including about existing architectural and other design patterns, knowing when to negotiate with the customer over the inclusion or framing of one or more requirements, knowing how to convert quality requirements into a functional solution e.g. to satisfy a performance requirement that states that the user response time at an ATM must be no more than 2 seconds for every transaction (very tough!) the architect may translate this into a functional requirement to minimise the number of communication paths between the user and the data to be retrieved, conceptually and physically.

There is no formulaic architectural design process for any system. However, the process of Architectural Design does not just rely on finding a blank piece of paper and hoping for inspiration. It often begins with a short time-bounded feasibility stage that consists of the generation of different feasible concepts for arranging the design as a whole from which one is developed into an architectural design. Both feasibility concepts and the development of the selected architectural design are creative activities that use a combination of different design techniques set out in section 2.6 General Design Techniques and move iteratively through the steps in sections Define the System Context to Define Principal Components below. In some circumstances when the type of system required has been built before there may be a domain-specific architecture (see section 6) that can form the basis for the new system.

Define the System Context

The starting point for a functionality-based architectural design process is to define the system context, the boundaries of the systems and the actors with which it must interact. Some of this may already have been done during Requirements Engineering (RE), but the focus of RE is on what information the target system must produce, for whom and hence what it may need, rather than how it is going achieve that and what other systems it may need to interact with.

A Context Diagram shows the system under consideration as a single entity and then shows the relationship that system has with other external entities people and systems. For example, Figure 3 shows a generic system context diagram overlaid by a Fire Alarm System. Figure 4 develops the specific detail. Users will provide and receive information. Superordinate systems are those that use the target system (these may not exist of course in some applications) e.g. a fire alarm system will be part of a building security system. Subordinate systems are external systems that the target system depends on for information e.g. a fire alarm system is dependent on small sensor systems and actuator systems. Peer systems are those that interact with the target system but address a different domain e.g. a fire alarm system provides information to a device maintenance monitoring system. The advantage of a context diagram is that it is straightforward to understand and can benefit a wide audience including stakeholders, business analyst, data analysts, developers.

The detail of the interfaces to each of these systems needs to be defined as do associate quality requirements e.g. performance, security. The key here is to focus on high-level abstractions rather than the detail say of the data that is to be transmitted at each interface unless such detail will be architecturally significant. Note too that interface definition can become more complex in the case of product line architectures when different product variations require slightly different interfaces.

The context diagram is a communication tool so there can be some flexibility over the contents and the symbols used to draw them provided they are well-defined, and everyone understands what they mean. For example, the consideration of different system categories as superordinate, subordinate and peer is simply a means to help understand what systems the target system must interact with. You may choose other categories that seem more natural to you or the context you are working with. Similarly, data stores created and used explicitly by the target system are not normally seen on a context diagram because they are part of the target system. However, with the storage of data often now being outsourced to third party (“cloud”) data storage solution providers e.g. Amazon, Google, Microsoft, these data stores may be shown.

Define Archetypes

Archetypes are the very typical high level abstract entity that captures the structure of particular type of system. Often these archetypes are connected to each other to form an architectural pattern. As the detail of the design evolves these abstractions may be populated and/or instantiated. Identifying archetypes and hence architectural patterns is a creative process and requires the use of the design techniques in section General Design Techniques. Different engineers disagree on what is an archetype and what is a principal component (section Define Principal Components). It is a matter of granularity. In the examples below, the archetypes are regarded as the overarching architectural structure that is common to that type of system.

Example 1 – Enterprise Information System

Enterprise Information Systems e.g. bank accounts, flight check-in information, hotel reservations, concert ticketing system are characterised by the provision of access to information and/or other resources e.g. cash, tickets, to many users. The data sets are usually large and accessed concurrently often through web browsers. User actions can not interfere with each other and the integrity of the database is maintained. Figure 5 shows the archetypes of an EIS organised in different Layers (see Layered pattern in Chapter 3).

Layer 1:

A user interface component (often a web browser) allows a requester of a resource to issue queries and requests for the resource to be allocated.

Layer 2:

A user authentication component checks that resources are being allocated to an accredited requester e.g. in an event booking system this could be a valid credit card. A resource delivery component prepares the resources for delivery to a requestor e.g. in an event booking system, this might involve preparing an e-mail confirmation to the requestor and an email to the distributor saying where and when the tickets should be posted. A query management component allows users to discover what resources are available e.g. in a ticketing system, this would show what tickets are available on what dates.

Layer 3:

A resource management component allows a resource provider to add, edit or delete resources from the system. A resource policy control component describes the rules of resource allocation e.g. an event ticketing system often restricts the number of tickets a requester can buy. A resource allocation component updates the resource database when resources are assigned and associates these resources with details of the resource requestor.

Layer 4:

A resource database component holds details of the resources being allocated. Resources may be added or removed from this database e.g. in an event ticketing system the resource database includes details of all bookable tickets. A transaction processing component includes resource-locking facilities so that the same resource cannot be allocated to users who make simultaneous requests.

Many organisations wishing to construct an Enterprise Information System do so by purchasing an EIS platform, containing all these Principal Components, from a vendor e.g. Oracle, SAP, IBM, Microsoft. The purchaser then works with the supplier to populate the platform with its own business rules and data.

Example 2: Event-based System

Event processing systems respond to external events in the system’s environment. The type of event and its timing are unpredictable. Some systems have a user interface e.g. word processors or computer games take information from a keyboard or mouse. Some systems just receive data from other systems e.g. weather information systems receive data from ground and wind sensors, jet aeroplane engine management systems receive information from ground-based computers, weather radar systems, altimeters, and other sensors attached to on board mechanical and electrical engine parts. Figure 6 shows a Fire Alarm system as an example of an Event-based System. The archetype is an abstraction of three principal components: an input data processor, a controller that prioritises the processing of the data to be done, and an output data processor.

Example 3- Batch Processing System

Batch Processing Systems are transaction processing systems that run over a large number (millions) of records. Completing these transactions (e.g. calculating and adding the annual interest to all those bank accounts that merit it) can take many hours. Data is input and output in fixed size “batches” from a file or database such that the CPUs are not solely locked up processing this data but can enable users to undertake other work as well. Many financial services organisations use back-up facilities offline magnetic tapes and/or disks, which must be physically loaded and unloaded by operators when they get full.

Figure 7 shows the archetype for a batch processing system as an input data reading component, a data processing component, an output data writing component and a database. An input component collects inputs from one or more sources; a processing component makes computations using these inputs; and an output component generates outputs to be written back to the database and printed. For example, a bank takes customer records for its ISA accounts (inputs) and calculates annual interest for each account (process) and then prints updated statements (outputs) for each customer.

The input, processing and output components may themselves be further decomposed into an input-process-output structure. For example: an input component may read some data (input) from a file or database, check the validity of that data and correct some errors (process), then queue the valid data for processing (output). A processing component may take a transaction from a queue (input), perform some computations on the data and create a new data record recording the results of the computation (process), then queue this new record for printing (output). Sometimes the processing is done within the system database and sometimes it is a separate program. An output component may read records from a queue (input), format these according to the output form (process), then send them to a printer or write new records back to the database (output).

The nature of data processing systems where records or transactions are processed serially with no need to maintain state across transactions means that these systems are naturally function-oriented rather than object-oriented. Functions are components that do not maintain internal state information from one invocation to another. Data-flow diagrams are a good way to describe business data processing systems.

Define Principal Components

Having defined the archetypes, the next step is to define the principal components. In fact, some principal components will have been identified in the archetype but there may be more. A software component is a unit of data and/or functionality with contractually specified interfaces and explicit context dependencies in the context of a well-defined architecture. This definition enables a component to be object-oriented or functional oriented. Component description during architectural design focuses on its purpose, its interface i.e. how it is used by another component, and which other components it will use. The internal data structures and processing details of the component are undertaken during detailed design (see Ch. .4).

There will be different types of component corresponding to the four dimensions of a computer-based system (CBS) (Chapter 1, 📷 Figure 1): interface components, controlling architecture components, data processing components and data storage and access components, as well as communication components to enable the CBS to communicate to other systems. Within these high-level abstraction categories there will be a wide range of components.

The particular order that different engineers will develop principal components will vary because people often tackle problems in different ways, and because the complexity of different system types is located in different aspects. Four complementary approaches to identifying principal components are:

i. to focus on the main application domain entities that emerge from the requirement specification that might form classes.

ii. to focus on where the greatest complexity is likely to lay e.g. e-commerce systems often have many different complex user interfaces providing access to and understanding of a small number of data types. Forecasting systems often have straightforward input interfaces to a modest number of data sensors and hence data types, but they collect streams of data types and must undertake a range of complex interacting functional data manipulations and calculations, so one might focus more on these data processing components first.

iii. to focus on the deployment infrastructure e.g. memory management components, database components, communications components.

iv. to focus on the interfaces in the context diagram. For example, in a commercial fire alarm system, the interfaces may be to (i) a physical Detector device (which provides data from its smoke and/or temperature fire detection sensors) (ii) a set of Alarm Response Devices e.g. alarm bells, fire extinguisher system (iii) a Building Health & Safety Monitoring System that alerts human operators and has a direct connection to a local Fire Service system.

Principal components are recursively decomposed during Detailed Design (Ch. 4).