Architecture

Software Architecture is the art of defining the logical and physical structures of software systems.

The Architecture of a system is a hierarchy built up by the definition of new Languages using other, already existing Languages. A Language is defined with an implementation contained in a Component.

The first task for the architect is to decide which operating systems, programming languages, software libraries, communication protocols, databases, file formats and user interface toolkits to use. The second task is to arrange them in a structure that enables reusability of Components and adaptability to changing requirements.

The Architecture can be viewed from three different focal points. They are the Logic, the Transition and the Deployment view.

Architecture vs. Design

Software Architecture is related to software design, but they are not the same. A Language implementation is designed, Component interaction is architected.

The table below compares Architecture and object oriented design.

Architecture Object Oriented Design

Scope Component interaction Language implementation

Specification Language Interface

Body Component Class

Circular Dependencies No Yes

When the Architecture is created and the system is broken down in Languages and Components from the top down, there exists a limit where the Architecture can go no further. At this point, the system development switches to Language design and implementation. Theoretically, this limit is where cyclical dependencies between software constructs are necessary. It is no longer possible to split up the constructs in two or more well defined Languages. This limit is called the architectural horizon. In practice, Language design and implementation are started earlier than this extreme.

The Architectural Horizon.

Architectural Views

The Logic View is focused on the Components specifically developed for the system, the Languages they implement and the source Languages used for their implementation.

The Deployment View is focused on the physical deployment of executable Components on a single node or in a distributed computer system. External Components necessary for the execution of developed Components are also included.

The Transition View is focused on the translation of the Components in the Logic View to the executable Components in the Deployment view.

Architectural Testing

As the Components are arranged in a tree structure without cyclical dependencies and only depend on lower level Components, it is natural to test them in a bottom up fashion. Each Component should be equipped with an automated test suite, run in the order of dependency, starting with the Component with least dependencies.

If it becomes necessary to create a test stub to replace an untested Component, the Architecture probably contains cyclical dependencies. Fix the Architecture and avoid creating stubs.

Agile Architects

In recent years, the concept of lightweight, agile software development methods has emerged. LISA can be used with good results in such an environment. The same fundamental architectural principles are at work, the models are just not as rigorously defined. Be aware of the fact that the agile gurus behind these lightweight methods have a lot of experience and can make the right architectural decisions based on gut feeling. If you are not as experienced, more detailed work will have to be done to achieve a reusable and flexible architecture.