Software Architecture

Software architecture is high-level design, but the term invokes the building metaphor. It is a high-level view that hides implementation details, but still identifies the key software modules, which components communicate with each other, and clarifies the roles and responsibilities of the various subsystems after determination of the important interfaces. A unified vision of how the software should be adapted allows a large team to develop the program more elegantly. The architecture is the single largest influence on the design and future growth of the software system, and it is essential to get it right in the early stages of development.

It may be important to specify particular hardware components, or the number of machines and processors in a distributed system. It may also describe specific algorithms or data structures if they are fundamental to the overall design.

There are four points of view commonly recognized in the architectural process. The conceptual view, also sometimes called the logical view, shows all the major parts of the systems and their interconnections. The implementation view is seen in terms of the real implementation models. The process view is designed to show the dynamic structure in terms of tasks, processes, and communication (best used when a high degree of concurrency is involved). The deployment view shows the allocation of tasks to physical nodes in a distributed system. Here we concentrate on the conceptual view which is the main result of the initial architectural phase.

The architecture is captured in a high-level document called something like the architecture specification. It is the initial system design and the first development step after the requirements have been agreed upon.

Architecture mostly concerns itself with components and connections. A component could be an object, process, library, database, or third party product. Each component is a clear and logical unit. Connections may be simple function calls, data flow through a pipe, an event handler, or a message. It can be synchronous (blocking the caller until the implementation has completed the request) or asynchronous (returning control to the caller immediately and arranging for a reply to be posted back later).

The key is simplicity. There should be neither too few nor too many components. Too many fine-grained components lead to an architecture that is hard to work with. Too few components mean that each is doing too much work and the structure is unclear. A good architecture leave space for maneuverability, extension, and modification, but it is also not hopelessly general.

It is key to recognize the architectural style to work with the existing software sympathetically.

No architecture as pasta is the pasta ball.

Layered architecture is the most common style in conceptual views. This describes the system as a hierarchy of layers. A famous example is the OSI seven-layer reference model for network communication systems. The lowest level is usually a hardware interface. The highest level is the interface that the user interacts with. Layered architecture as pasta is lasagna.

Pipe and filter architecture models the logical flow of data through the system. It requires a well-defined data structure between each filter. Pipe and filter architecture as pasta is the cannelloni.

Client/server architecture divides functionality itno the client and server. Sometimes this approach is known as a two-tier architecture. As pasta, it is gemelli.

Component-based architecture splits control into a number of separate collaborating components rather than a single monolithic structure. This kind of design arrived with the lure of assembling applications quickly out of prefabricated components. The core is a communication infrastructure, or middleware, that allows components to be plugged in. Common middleware platforms include CORBA, JavaBeans, and COM. As pasta, conchiglie.

Frameworks basically give you an architecture. A traditional library is used by your thread of control making explicit calls into the library components. A framework turns this around: it manages the thread of control and makes calls into your supplied code. As pasta, canned ravioli.