Architecture before specification; client-server

Why architectural design comes before detailed specification

In practice requirements engineering and architectural design overlap. A high-level architecture is usually proposed before the detailed system specification is written, for these reasons:

1. To structure the specification – a large system cannot be specified as one block. The architecture breaks it into sub-systems, and the detailed specification is then written sub-system by sub-system.
2. To allocate requirements – each requirement can be assigned to the sub-system that will satisfy it, which helps traceability and shows gaps or overlaps.
3. Parallel work – once sub-systems and their interfaces are known, separate teams can specify and develop them in parallel. Sub-contracts are also based on sub-systems.
4. Non-functional requirements depend on structure – performance, security, safety, availability and maintainability are largely decided by the architecture, so the designer must know the structure to write realistic, testable non-functional requirements.
5. Interface definition – interfaces between sub-systems (and with other systems) must be fixed early; they become part of the specification.
6. Feasibility and cost – an early architecture lets the team judge whether the requirements are achievable and estimate cost before committing to a detailed specification.
7. Reuse decisions – deciding early to reuse an existing architecture, product line or COTS sub-system changes what needs to be specified.

Client-server architecture

A client-server architecture is a distributed system model in which the system is organised as a set of servers that provide services and a set of clients that use those services, connected by a network.

Main components:

1. Servers – provide specific services, e.g. file server, print server, database server, web server.
2. Clients – request services from servers; there may be many clients running at the same time.
3. Network – lets clients reach servers, usually using request–reply protocols (e.g. HTTP over TCP/IP).

Clients must know the names of the servers and their services, but servers do not need to know the clients.

The application is usually divided into three logical layers: presentation, application processing and data management.

• Two-tier, thin client – the client handles only presentation; processing and data are on the server.
• Two-tier, fat client – the client also does application processing; the server manages data.
• Three-tier – presentation, processing and data run on separate machines, which scales better.

Example: internet banking system (three-tier)

  Tier 1           Tier 2              Tier 3
  (presentation)   (processing)        (data)

+----------+
| Browser  |--+
+----------+  |   +-------------+    +------------+
+----------+  +-->| Web server  |--->| Database   |
| Browser  |----->| (login,     |    | server     |
+----------+  +-->| balance,    |<---| (accounts, |
+----------+  |   | transfers)  |    | transac.)  |
|Mobile app|--+   +-------------+    +------------+
+----------+
   requests go right, replies come back left

A customer logs in from a browser (tier 1). The web server (tier 2) checks the login, calculates balances and handles transfers. The database server (tier 3) stores customer and transaction data. More web servers can be added when the number of users grows.