Strandz is the middle layer that connects a Java Swing UI with the backend, employing a strict Model/View/Controller structure to enable the rapid development of maintainable code. It is an API that enables developers to productively connect users with their data.

Strandz applications are made up of a small amount of controller code combined with some high level building blocks. This means that they will be completed significantly sooner than comparable Java Swing applications, bringing development costs down. Additionally these high level building blocks are common to all Strandz applications, which means that their stability should be able to be relied upon.

One of the implications of the loose coupling design approach taken by Strandz is that the actual applications will be able to cope with ongoing specification changes and changes to related software components. For instance changing the application-housing/L&F, the way that data is stored, or the UI toolkit that is used are all realistic possibilities.

Strandz has not opted for a code generation approach, which is used for example by Model Driven Architecture (MDA). Such an approach has the unfortunate side effect of producing two places where maintenace can be done - in the code itself or through the generator. Once you start to change the code you are no longer allowed to generate, as you risk overwriting your changes! There are ways around this round-tripping predicament, but they force the programmer to make some unnatural design decisions. Rather Strandz takes a more dynamic approach in that you are always dealing with the same object model, whether that be at design-time or runtime. One of the implications of this is that Strandz is flexible enough to be able to handle fine grained UI requirementments.

If you need a refresher on what exactly the Model/View/Controller Paradigm is, then this straightforward definition will help. However, note that Strandz makes MVC simpler than this, as the controller does not necessarily need to reference the view:

Strandz takes the concept of Model/View/Controller possibly as far as it can go. These three separate areas of developer attention work together at only at the highest possible level of abstraction. This article describes the Passive View pattern which Strandz reifies. One the advantages of using a framework is that the patterns you need are already there.

Strandz views are always dumb. They might be able to change something about their appearance due to a user-command, but that will be the extent of their control aspect. Similarly any model aspect the view may have will also always be appearance related. More formally this is know as Separated Presentation.

A whole Strandz application can be written and verified with unit tests before any screens have been developed. Martin Fowler refers to this as 'subcutaneous testing' in an article called Organizing Presentation Logic. The way that Strandz achieves this is quite simple - a Strandz application can be written to never refer to controls directly, but instead to refer to them indirectly through attributes. In turn these attributes can refer to dummy controls just as easily as real ones. To make the swap you just need to change the type of attribute that is used.

The following is the view of another industry heavyweight:

"I don’t like user interface-based tests. In my experience, tests based on user interface scripts are too brittle to be useful. When I was on a project where we used user interface testing, it was common to arrive in the morning to a test report with twenty or thirty failed tests. A quick examination would show that most or all of the failures were actually the program running as expected. Some cosmetic change in the interface had caused the actual output to no longer match the expected output. Our testers spent more time keeping the tests up to date and tracking down false failures and false successes than they did writing new tests."

The above is a quote from Kent Beck. The source can be found under the heading Philosophy at Extreme Programming Test Framework.

Having a high level controller makes the code easy to maintain. If you want to know where the code for a particular field's validation is to be found, there is only one place to look. If you want to know what happens when the user indicates a commit, there is only one place to look. And so on for any event that a user might trigger. This kind of maintainability is quite possible with 4GLs. Strandz differs from 4GLs in that the controller sits on top of a reasonably complex model. This complexity keeps the actual controller code simple.

The model is at the heart of Strandz. It is structured as the combination of many instances of four Strandz classes. These classes allow the developer to describe how the user will interact with the database. For instance, the developer may wish the user to be able to navigate through the Orders the user has queried, always having available only the OrderItems for the currently selected Order domain object. Furthermore, the developer may wish current OrderItems to be view only, and each one to look up an image of a Product.

The Strandz model is concerned with master-detail relationships between visible records. Each of these visible records may actually be made up of many domain objects which have a lookup relationship to one another.

From our example we can see that there was a master-detail relationship between one Order domain object and many OrderItem domain objects. The master record was made up of only one domain object, an Order. The detail record was, however, made up of both an OrderItem and a Product. The OrderItem is said to have looked up the Product. These relationships can get as complicated as you like, we have just chosen to show you the simplest possible example.

Strandz attempts to ease the burden of application development by putting behaviour that is standard across almost all applications into a model form that can be specified at design-time and then if necessary altered at runtime. There are productivity benefits to be gained from this approach, one of which is that test-driven development can proceed without a UI layer, making the unit tests less fragile.

We have used this colour to denote a pattern. All the patterns on this page are Martin Fowler's.