A software architecture is a decomposition of a software system
into sub-systems or modules. These modules should be more or less
independent. Remaining dependencies and control relationships (i.e.
which module(s) is/are the boss) should be expressed in the model.
Developing an architecture is part of software design. While
decomposing the individual modules further one finally reaches detailed design,
which is usually done with object-oriented models, functional models,
data flow diagrams, .... .
A software architecture gives the software engineer an overview
of the system, helps to define APIs and to communicate his ideas to
his peers. It also allows to use something similar to software
patterns on an architectural level to make it easier to re-use
knowledge. Some standard architectural patterns are :
More structural 'patterns':
- Piped architecture:
- The different modules are
organized as an assembly line with each module doing only part of
the job and providing its output as input of the next one. Typical
for UNIX shell scripts.
- Blackboard architecture:
- All modules place their
results in a central area (the blackboard) and fetch new input from
there. Every modules sees everything. Typical for some AI systems.
- Client-server architecture:
- Each server provides
specific services to everyone caring to ask it. It may use services
of other modules and can therefore be a client at the same time.
Servers may be active (e.g. to exchange information with peers). The
user is using clients, but in reality he may be interacting with a server
(e.g. the X-server). Used by a lot of systems, especially
distributed.
- Layered architecture:
- Modules are organized in several
layers and each layer uses the next lower (and only it) to provide
services for the next upper. Makes e.g. security easier. Used e.g. by
former operating systems (don't ask me about current).
More control 'patterns':
- Main program sub routines architecture:
- A central
module calls others (which may again call sub-modules of them),
forwards intermediate results and stays in control all the time.
Typically found in most programs not using threads or interrupts.
- Event-based architecture:
- The system reacts on
external events (from e.g. the user, the OS or some sensors) by
dispatching them to an appropriate module where they are handled.
- Table-driven architecture:
- Most of the control logic
is embedded in some data structure which is 'interpreted' during
program execution. Examples are YACC-generated compilers and
state-machine-based systems.
To summarize: Use
them! ;)
<architectures partially taken from a technical
report of David Garland and Mary Shaw, the distinction into
structural and control architectures is from "Software
Engineering" by Ian Sommerville>