Architectural Patterns

An Architectural Pattern is a common arrangement of Components that can be reused in more than one System Architecture. They are used to solve reoccuring problems and communicate solutions in the System Architecture.

The Architectural Patterns presented here have a different focus than the traditional Architectural Patterns found in the litterature. The traditional approach is to present a solution applicable to a specific problem domain. In LISA, a pattern is a common arrangement of Components and Languages that addresses a generic problem that can be found in many problem domains.

Problem Partitioning

Big components require a lot of coordination between developers when they are implemented. The test effort grows exponentially with the size of a component. Large components are more difficult to reuse. These are the reasons to partition a component into smaller components that solves parts of the whole problem.

The problem is partitioned.

The Application Stack

A useful initial approach to program decomposition is the application stack.

Type 1: End User Program Type 2: Reusable Program Type 3: Reusable Library

This is a program intended for an end user. This is a program intended to be used as a Baseline Language. This is a Domain Language intended to be used as a Baseline Language.

The split between User Interface and Application makes it possible to use automatic test scripts for the Application teting. A User Interface is usually quite difficult to test with automation, especially if it is a Graphical User Interface.

The split between Application and Domain Language usually comes naturally, either from the requirements formalization effort or through problem partitioning. The reason to do this split is that Domain Languages are reusable in other Applications, and Applications alone have much less reusability potential on their own.

The three components User Interface, Application and Domain Language can also be used when analyzing an existing Architecture. It is very useful to break an Architecture down into these simple Components to find opportunities for reuse, architectural faults and ad.hoc. Languages.

The Generic Solution

A problem can usually be solved in two steps. First, solve the generic problem. Then use the generic solution to formulate the specific solution to the problem at hand. This approach creates a natural division of work between the developers, it improves reusability and it reduces problem complexity.

Using a generic solution for a specific.

The Configurable Component

The Pragmatic Programmers said it best, "Put Abstractions in Code, Details in Metadata".

This means that as much configuration data as possible should be left outside the core Component as metadata. This has the implications that it is easier to reuse the component and it is also easier to adapt it to changing requirements. The metadata reconfigures the behaviour of the configurable component at runtime.

The Component is configured with Metadata.

The configurable component is related to the generic solution. The major difference is that the configurable component has a more dynamic behaviour than the generic solution.

The Code Generator

If performance is a high priority, it could be necessary to use a code generator. A common case is when there exists a set of formalized requirements that are too slow to interpret. A code generator usually translates from a domain specific language into a generic programming language. It is also necessary to use the code generator if you want to use the typechecker in a standard compiler for your domain types.

Code generator.

Embedded Scripting

Embedded scripting is a special form of code generation, where most of the result is known and just needs to be filled in with details. The code generator reads a hybrid language, where scripts are mixed into the code. The generator executes the scripts, and inserts the result in their place.

Embedded scripting can also be used to create dynamic templates.

Scripts embedded in template.

Traditional Architectural Patterns

Two common traditional Architectural Patterns are Client-Server and Model-View-Controller. They are each analyzed on separate pages.