|
Architecture
|
A system's most important partitions and their relationships, preferably the result of careful planning.
For example, it was popular at one point in OOAD to partition most systems into the standard architecture of User Interface, Business Logic, Persistence and InterSystem, with the first three layered and all three using InterSystem. This is still a very sound starting point.
Here's another example, from Jester, a Java testing tool. The first thing one sees is the three partitions. Then one sees the relationships. Due to the importance of Architecture, let's take the time to discuss this example, bringing various other concepts to the table as we dwell on details.
The architecture emerged in conjunction with early class modeling. It uses the exquisite Layer Pattern. The basic rule is a layer can call down but not up. The Tester partition has the root Test and manipulates the tree of tests using the root Test as the entry point. The GUI tells the Tester to run a suite of tests. These three partitions are very independent and can be freely substituted due to the loose coupling designed in, using Java interfaces as plugpoints.
However layers do need to do the equivalent of calling upward. This must be done using super loose coupling. Otherwise an upper layer is too tightly bound to a lower to layer to swap out the upper layer.
To call upward, the Test Cases partition throws exceptions when problems occur, such as AssertFailureException. These are caught by the Tester, results are recorded, and the suite of tests continues running.
To call upward, the Tester partition emits events when the state it wants to publish changes. These events are received by the GUI layer and instantly show up on the visual tool. For example if an assert failure occurred it would be added to the list of failures and the failure count would be incremented.
Not shown on the diagram is the key plugpoint - the Test interface in the Test Cases partition. This is what the entire design revolves around. The test cases must all implement Test. To make this easier a default implementation (TestCase) is provided for eacy subclassing.
The conceptual integrity of Jester consists of the invisible claylike molding the three layers and Test give to any developer using the product. Generally one is never aware of much more than TestCase and a few helpers. The rest of Jester lies outside the test writer's "field of confusion", simplifying, satisficing and helping them along in a lightweight, transparent manner.
Architecture is the backbone of system design. It requires good abstraction and modeling skills. It is enhanced by deep and continuous study of the literature and products. As OO guru Grady Booch says,
"Software should be architecture driven."and
"With regard to architecture, the first question to ask is simply,
'Is there a defined architecture?' "
![]() |
Use architecture to give a system its skeletal backbone. The rest is ribs and flesh. |