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.
|