Here we are going to take a very high level view of the structure of a Strandz application, before examining how we might translate an existing application into Strandz. Although in general we stick to the translation perspective, the same theory applies where a greenfield application is being written.

Strandz applications can be built without the need for them to have any visual representation. This makes the API well suited to test driven development. With the panels making up such a thin layer, then when we unit test to a level just below this layer, we are actually still testing a high percentage of the code.

A purely structural SdzBag is one where the attributes have not been bound to any items. As a container of all the application's other SdzBeans, a SdzBag gives us a definition of the limits of an end-user's possible interactions with data: which domain objects can be navigated through, how different data values will stay in sync with one another during navigation, and what domain object records are allowed to be inserted, deleted and updated. A purely structural SdzBag is a description of the model aspect of a process-path, and encompasses the model aspect of all the layers up to the UI layer.

In MVC terms we have now only have the control aspect left to examine. The control aspect of a process-path might be something like "Record Customer Purchase". The first user-process might be to type in the customer's name and press the query button so bringing up the customer record. What a user-process is is probably a little subjective. In Strandz terms if it is interesting enough to require a trigger that is activated by an action-item then it is a user-process. Thus if there was an item validation trigger on surname then just entering the surname would be a user-process. However, navigating to the next customer would not make it as a user-process unless it caused a navigation trigger to be fired. (In this case you can still think of a user-process existing, but it is purely under the control of a particular Strandz application-housing, and thus does not need to be tested for a particular application).

As a developer's knowledge of an application-domain increases he is able to design the domain object model, then the SdzBeans, and finally the control aspect of a process-path. Generally speaking it would be hoped that this ordering also reflects decreasing code stability, although oftentimes maintenance affects both the model and control aspects of a process-path. Although these areas are separated in any Strandz application, from a human knowledge point of view they are inter-related. If you are designing or coding in any one of these three areas, then you will have a good knowledge of the other two.

We have purposely left out UI design/maintenance as we are tracing out a methodology whereby a whole application can be written and tested independently of the UI. We can thus leave the application-housing and the rest of the UI (the panels) until later.

Any well written application can be translated into Strandz, and in fact the translation process would provide an audit of just how well structured the original code was. For our purposes we are going to assume two things into the definition of a well written application. The first is that it uses an object-relational binding layer to update the data, and the second is that it uses business objects.

It is intrinsic to using a business objects based approach that all domain layer logic exists within them. In practice this will probably always be contravened to some extent in a interactive rich client application, especially where validation is concerned. Another part of the definition (from a Strandz point of view anyway) is that business object classes only import the data and store packages. The package data.application-domain.business would only depend on the packages store, store.application-domain and data.application-domain.objects. Of course many other external/server-side container services can be called upon by business objects. There will be no interaction with the user interface.

In a project to translate a legacy application into Strandz you might use various means to discover what the process-paths are. In terms of project tasks this discovery would be task number one. Number two would be to translate the panels into Swing if they exist in some other form. These two tasks are unrelated when translating a legacy application, so neither will hold the other one up. (In the case of a greenfield application if you didn't know what the end-user was going to do you couldn't very well design the screen, so the two tasks are obviously not actually disconnected).

As each process-path is understood a structural SdzBag and the triggers (a trigger is the starting point for a user-process) that act upon it can be written. Once this is done the programmer can write a unit test for the process-path. The screens/panels can be left unattached right until the end, or alternatively can be attached at the time the SdzBean is written. A benefit of coding the triggers before attaching the screens is that it forces the triggers to be written in a style that does not refer to items, or rather refers to them only through attributes. With this style all triggers will in effect be disconnected from items. This will make it easier to say swap in different screens. Thus to take an extreme example all the application code could remain the same, but Swing screens could be replaced by screens from a different UI toolkit.

Test cases could certainly be written without access to the screens if necessary, but in practical terms it would be good for the unit test coder to be able to look at the screens. After all a JUnit test method is just the scripting of a series of user-processes, each of which is activated by an action-item, which is best visualised by looking at the actual screen that contains the action-item.

As long as every new item can be placed behind an attribute then the methodology we have described here can be applied. Complex controls such as JList and JTable can be accessed via attributes. However there are some controls that are difficult to imagine as being visually contained within nodes. If such controls are to be used in the same way across your application then they make ideal candidates for inclusion as part of the application-housing. In the Wombat Rescue application the Alphabet Bar is an example of such a candidate.

We have taken a quick look at a disciplined approach to development that Strandz makes possible. Whilst it could feel quite unnatural to be writing UI code without any screens, this approach will tend to encourage unit tests to be written right from the beginning, and make clear the delineation between portable and non-portable code. It is important to note that any Strandz application, no matter how it has been developed, is test-friendly.